Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 02/10/2013 04:24, IKEDA Soji a écrit :
> Though comment below might not so benefical...
>
> On Tue, 01 Oct 2013 17:25:13 +0200
> David Verdin <address@concealed> wrote:
>
> > > > > Now; for the Site_r concept, I'm puzzled: what is a Site_r object
> > > > > supposed to be ? And how is a mailing-list a specific kind of Site_r ?
> > > > >
> > > > > If Site_r is just a place holder for generic code, it should better
> > > > > get renamed as 'Object', 'ConfigurableObject' or some other name
> > > > > following 'qualifier-noun' pattern.
> > > > Site_default ?
> > > A list is still not a kind of 'Site default' :)
> > :-P
>
> In my mind, "r" intended "reticent" --- describing that it is _not_
> configable object and in consequence it has no getters/setters.
A better name in that case would have been ReticentSite. I'm myself far 
less reticent to explicitly named concepts than to ad-hoc abreviations :)

> Instead, it bears common nature of other types of objects (Site,
> so-called Robot and List): Each of these objects provides particular
> e-mail addresses, URLs, file paths etc.
>
> Anyway, I'm not an expert on design pattern.  I'll watch
> discussion on this point.
Given the current class topology:
- a list object is an instance of the List class
- the List class inherits from the Site_r class

It results than a list object is both an instance of the List class, but 
also an instance of the Site_r class. As you defined the Site_r class as 
'something which is not configurable', it means than a list is not 
configurable. Probably not what you meant :)

However you problably meant than Site_r was supposed to be an abstract 
class, not to be instanciated directly, right ?

--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME