[squeak-dev] Re: Menu Registries
Andreas Raab
andreas.raab at gmx.de
Wed Apr 28 03:29:39 UTC 2010
On 4/27/2010 12:00 PM, Nicolas Cellier wrote:
> 2010/4/27 Hannes Hirzel<hannes.hirzel at gmail.com>:
>> What are the reasons for not going for the Pharo solution?
>
> Andreas just put it nicely.
> There is a different philosophy, and that is important to discuss
> first, and weight pros and cons.
> The difference is that package maintainers should care of system
> evolutions in Pharo, but won't care of building details anymore in
> Squeak.
> Of course, this is at the price of restricting functionalities.
Indeed. But I consider that a Good Thing (tm). It means that we only
need to support what we explicitly agree on. One important thing to keep
in mind is that my take on annotations for service discovery is not a
"strict" requirement - for example you *can* use Preferences directly if
you need to do something unusual that isn't covered by the simple
preference annotation. You're simply losing the implied contract with
the community to keep your stuff running without your own help (which is
current practice). By voluntarily restricting yourself to use the
annotation we can support your work going forward, but if you need more,
please go ahead.
This is also why in the menu discussion the argument about "but you need
every possible permutation of menu creation" is simply a false
assertion. We don't. We can restrict ourselves to the subset that we
want to support. We then support it. If you need something that is not
part of the supported subset you have to modify the menu directly. Can't
be helped, because we don't support it.
We're doing this for preferences now (exactly one preference annotation
and not every conceivable permutation) and from what I see it works
great. I have no doubt that we will be able to support this for many,
many years because it's so simple. KISS, in short.
But the most important question to ask ourselves is: What problem are we
trying to solve here? If the problem is exclusively about extensibility,
then the Pharo solution would work fine. If it is about making this so
that people don't have to play catch-up every time something changes, I
think you'll find that the Pharo approach has difficulties in this
regard for reasons explained in my blog post at [1] (new with fixed code
font! :-)
I find the evolution of Pharo fascinating in this regard. First, there
was the desire to provide extensibility and loose coupling, so the
systemsettings annotation with builders were introduced. Then it was
probably considered too much bloat to keep all of this unused code in
the core classes, to the "Settings" package was created (I have no
reference for why the Settings package was created, if anyone has a
pointer I'd appreciate that). So now all the preferences builder code
has been removed from the places where the preferences are and into a
separate package. At this point you're not only maintaining the entities
in two different places (the domain code and the settings package), you
also loose the last reason for using annotations. There is no good
reason why Settings shouldn't depend on the builder framework - after
all it's a separate package, and it makes no sense to even load it if
you don't have the builder. And having the class initializer register
the preference is more obvious than having some 'magic' discovery under
the hoods. It might be "cool" but it addresses no discernible problem.
In short, if you're willing to split your code into domain and settings
packages you might as well declare the dependency of your settings
package on the settings framework. That's a perfectly legit way of
dealing with the specific dependencies, but at that point the use of
annotations becomes pointless.
[1]http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|