Thank you Andreas for the writeup you put at

'Annotations for Service Discovery'
http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/

I think it is well-written and is a must-read for everybody
participating in this discussion as it captures nicely the aspects
which were brought up so far.

The review how things went in Pharo is illustrative and in fact very
convincing for me to go for the annotations solution.

--Hannes

On 4/28/10, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
>
>