[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