Developers of Sympa

[Guillaume Rousse <address@concealed>]

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

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