Developers of Sympa

[Marc Chantreux <address@concealed>]

hello, 

On Fri, May 24, 2013 at 02:12:04PM +0200, Guillaume Rousse wrote:
> >so we can use roles to check that required are implemented
> I prefer this class hierarchy, which clearly separates concerns.

i'm not sure about this "this" in this assert :) 

> However, is there any interest to have some abstraction over spool
> content (message, key, whatever) ? After all, the calling code
> usually know which is expected content over each spool...  

> And have each of the two final classes implement distinct methods
> for storing distinct kind of content:
> Sympa::Spool::File::add_message()
> Sympa::Spool::File::add_key()
> Sympa::Spool::File::add_something_else()

It scares me right now as we'll quickly add some 

* if i have a spool with only 2 methods (say add and delete), i'm happy
  to see only 2 functions in the code and in the doc.
* what if you have 2 spool means have incompatible methods: you'll need
  extra code ? 

IHMO: Spool provides a basic interface that any spool mean can extend.
* Spool::Message ISA Spool
* Spool has Spool::Backend
* Spool::* contains every business method

> This doesn't prevent to have mixed-content spool by mistake, but
> code readability also helps to prevent coding errors :)

I don't thing splitting things this way would add a lot of complexity
but you might want to share some set of methods over Spool types: that's
why the roles are.

Basically: spools can be queues, trees, ordered or not, thread-safe or
not, ... maybe it's more that just a backend.

i'm confused for now. let the week-end help :)

-- 
Marc Chantreux
Université de Strasbourg, Direction Informatique
14 Rue René Descartes,
67084  STRASBOURG CEDEX
☎: 03.68.85.57.40
http://unistra.fr
"Don't believe everything you read on the Internet"
    -- Abraham Lincoln