Hello Stephane

On the Squeaklist there was a discussion ongoing since Monday how to
use to use pragmas in an extended way.

We agreed that they are in fact method annotations or method
properties which may be used for various purposes.

The name 'pragma' evocates compiler only related things which is true
but it is not limited to that.

Andreas had a good writeup in his blog (WORTHHILE READING)

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

So we want to go for pragmas (=method annotations = method properties)
to implement the discovery mechanism for populating the menus.

My question was: Why not do it like the Pharo people did?

Andreas' answer is copied in below. I.e. we want to learn from the
Pharo experience.


Regards
Hannes


----------------------------------------------------------------------------------------------------------------
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




On 4/28/10, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> Hi brent
>
>
> On Apr 28, 2010, at 5:47 PM, Brent Pinkney wrote:
>
>> Hi all,+
>>
>> Could those in the know comment on how this <...> proposal is (or is not)
>> consistent with the fundamental Smalltalk principles
>
>
> Sorry but I do not have the time to read squeak-dev.  so what is <...>  the
> use of pragmas?
> Or is there something else?
>
>
>> that:
>>
>> 1. "an object is send a message and responds with an object"
>> 2. there is no other "magic" in the system.
>>
>> Are we proposing a break fromv this ? If so, IMO we need to really get it
>> right before we commit.
>>
>> Thanks
>>
>> Brent
>>