Re: [Seaside-dev] Configurations, again…

[Philippe Marschall]

2011/7/18 Julian Fitzell <jfitzell at gmail.com>:
> Let me try to get my head back into this and think about it...
>
> Off the top of my head, it seems like having multiple parents is
> essential to allow addons to support custom attributes for a request
> handler.

Does anybody use this? In addition I would assume that every time you do
WAAdmin clearConfigurationCaches
they would manually have to be "reinstalled".

> I'm not a big fan of using subclassing any more than
> necessary and the parents are a form of delegation.
>
> I also don't understand why you're talking about using classes instead
> of singletons (at least that's what I think you're suggesting).

Subclassing is the natural way to model specialization in Smalltalk.
When WAApplication is a subclass of WARegistry I would expect
WAApplicationConfiguration be a subclass of WARegistryConfiguration.
Otherwise when does WAApplicationConfiguration have to have a parent
of WARegistryConfiguration? Always? Sometimes?

Also subclassing makes it easier to customize the descriptions. For
example I can just subclass and override #libraryClasses. I don't have
to copy and paste the whole attribute definition. The code is also
easier to debug, there is no custom multiple inheritance which
multiple parents where I don't know what takes precedence over what.
It's just Smalltalk method look up rules which everyone is familiar
with.

The singletons introduce a "deploy" cycle, every time you change a
configuration you have to "redeploy" (reset the singleton).

And singletons suck.

> In
> this case, even if there was no other reason to avoid that (which I
> think there is), those classes share behaviour with the user
> configurations, don't they?

No, not at all. The WA*RequestHandlerClass*Configuration would just be
description factories through the #describeOn: method. The user
configuration would just store the configuration values. There would
be no overlap at all between the two.

Cheers
Philippe