Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi,

Anyway, I had a chance to express my position.  If someone thinks
"get_" prefix helps understanding by coders, I can not prevent it.

Use of AUTOLOAD is another issue: It is not a "magic".  Dynamic
methods are ordinary things on some programming languages.  I
simply used it to implement methods lookalike "attributes".


In the next post I'll write about Site-Robot-List(-Family)
classification.

--- Soji

On Thu, 25 Jul 2013 13:02:07 +0200
Guillaume Rousse <address@concealed> wrote:

> Le 24/07/2013 15:06, IKEDA Soji a écrit :
> >> First, we have a vocabulary issue: what is an object attribute ?
> >> Here is is used as 'some kind of object property which is not a
> >> parameter', whereas for me, it is a plain synonym of 'object property'.
> >> For me, everything with an accessor is an object attribute, wether its
> >> value comes from a configuration file, is internally generated, etc...
> >
> > Currently, there are at least three categories of "attributes":
> >
> > (a) Mandatory paremeters of object, e.g. "domain" for Sympa::Robot
> >     object.
> > (b) Configuration parameter values related to the object.
> > (c) Values derived from parameters above, e.g. "sympa".
> >
> > I suppose (c) would be implemented by another way. Similarly,
> > other kinds of data structures such as "robot_by_http_host"
> > should be handled in different manner.
> >
> > So problem will be: What may we call (a) and (b)?
> 
> All our classes have mandatory (or not) properties defining them:
>    - a name for a list or a robot
>    - a subject for a message
>    - a file for a lock
>    - a type for a database
>    etc...
> 
> That's category (a). Let's call them object attributes, and let's use 
> accessors for them. Wether we use get_foo()/set_foo() or foo() model, as 
> well as wether they are to be statically or dynamically generated, is a 
> separated question.
> 
> Now, some of our classes, representing configuration elements (site, 
> robots), also have a huge list of configuration directives attached to them:
>    - a database name for a site
>    - a blacklist for a robot
>    - etc...
> 
> That's category (b). Let's call them parameters, and as they are a quite 
> large number of them, let's manage them through a generic 
> get_parameter() method, instead of specific accessors.
> 
> The point is than the database name, which is an attribute for the 
> database object, should not mandatorily be an attribute for the object 
> representing the configuration part where it is defined. And in fact, 
> not treating them as attributes would leverage the rest of the discussion.
> 
> For category (c), let's consider them as attributes, as per category 
> (a). That's the usual class-school discussion about get_x()/get_y() 
> accessors for a point object, wether they are mapped over actual 
> cartesian coordonates, or computer from radial coordonates.
> 
> What's about this proposal ?
> 
> >> Second, the spreading of attribute definition breaks object-modeling
> >> assumption than classes should be self-contained: the list of attributes
> >> for a robot object should be defined in Sympa::Robot object, not
> >> somewhere else (its specific attributes, of course, inherited ones being
> >> defined in its parent classes)
> >>
> >> Third, it clutters our API. I'm currently counting 17 public functions
> >> or methods in Sympa::Robot. Automatically generating methods for each
> >> element of confdef::params will add 258 additional methods...
> >
> > Methods never increase endlessly.  Fathermore, their
> > definition ends only at once: "They are configuration parameters".
> >
> > It is not always necessary to stick to treat them as subroutines
> > (functions), as constants are not usually treated as subroutines.
> Constants are internally implemented as subroutines, indeed. But they 
> don't clutter API, because:
> - they are declared using 'constants' pragma (use constant LOCK_FH => 1)
> - they are used a package variables ($a = Lock::LOCK_FH)
> Unless you know perl internals, there is now way to mix them with methods.
> 
> By mapping each of those 258 read-only configuration directives to an 
> object attribute, with its related read accessor, you are cluttering its 
> API, by stomping over the global method namespace. Sympa::Robot now has 
> 17 + 258 different methods. Sure, with enough knowledge of Sympa 
> internals, a human reading the API documentation will probably be able 
> to figure if $robot->request_external actually perform some kind of 
> action, or if it is a way to retrieve the value of some exotic 
> 'request_external' configuration parameter. But one of my design goal is 
> to reduce the need to read documentation, by making symbol name 
> self-explanatory.
> 
> Now, if you consider than you don't have to implement those 
> configuration directives to object attributes, but as a simpler 
> key-value store, accessed through a generic get_parameter() method, we 
> keep a far more reasonable API of 18 methods, and the difference between 
> $robot->request_external() and $robot->get_parameter('request_external') 
> doesn't present any ambiguity anymore.
> 
> Let's keep the rest of the discussion about 'how to implement attribute 
> accessors' for later, once we'll have an agreement over 'when do we need 
> attributes'.
> 
> -- 
> Guillaume Rousse
> INRIA, Direction des systèmes d'information
> Domaine de Voluceau
> Rocquencourt - BP 105
> 78153 Le Chesnay
> Tel: 01 39 63 58 31
> 


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/