Developers of Sympa

[David Verdin <address@concealed>]

Le 22/07/13 15:55, Guillaume Rousse a écrit :

address@concealed">Le 22/07/2013 15:04, David Verdin a écrit :

Le 22/07/13 14:53, Guillaume Rousse a écrit :

In Sympa::site:


sub get_etc_filename {
    Log::do_log('debug3', '(%s, %s, %s)', @_);
    my $self    = shift;
    my $name    = shift;
    my $options = shift || {};

    unless (ref $self eq 'List' or
    ref $self eq 'Family' or
    ref $self eq 'Robot'  or
    $self     eq 'Sympa::Site') {
    croak 'bug in logic.  Ask developer';
    }
}

That's absolutly ugly.

:-)
I love the way we can speak to each other without fearing ego fights. I
see it as a sign of good health for the Sympa project.

I refrained myself from writing 'crap'... Sorry, it was unecessarily rude.

No biggies. I mind it when I say we must be able to be frnak with each other; After all, our common aim is to make a better Sympa.

address@concealed">

Unless there is a class relationship between Sympa::List,
Sympa::Family, Sympa::Robot and Sympa::Site, those methods should be
defined separatly in those different classes, and should not spend CPU
cycles testing if they have been invoked on a correct instance.

That seems to make sense, however I don't remember the exact
relationship between these classes.
If I remember correctly, list and Robot both inherit Site. i don't think
Family inherits anything.

Then we probably need some renaming, or a better definition of what is a site, what is a list, and what is a robot. Because I don't see any explicit relationship between a site and a mailing-list...

Actually, I think Soji's idea is to ease configuration cascading.

address@concealed">
If the goal is just to share some code between those instance, the base class should probably called 'ConfigurableObject', for instance. And if sharing also means cluttering the code with 'what-kind-of-entity-am-i-called-upon', you lose all interest of code ruse.

Good proposal. I think inheritance between Site and Robot are obvious, because Robot objects do the same thing as Site, but at a smaller scale.
For the relationship between list and he two other, I think it is because you can call "object->parameter", this parameter being likely to exist both at list or virtual host level.

address@concealed">
BTW, code reuse should just be a side-effect of object modeling, not its driving pattern. For instance, I prefered to duplicate the methode to compute DBI connection string in Sympa::Database::* and Sympa::Datasource::* subclasses, just to make clearer than there isn't any relationship between the sympa mandatory database, and potential external sources.

Yes, I saw that, too.
At first, I wa like "what? Redundant code?" And then I saw it was a short version of redundant code and it made indeed clearer the separation of Datasources and database. Should the code grow, though, I think we should find a different organization; However, if we choose to use DBI::Skinny some day, this would probably reduce the impact of these modules.

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Infrastructure pour les Services Informatiques
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

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