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<[email protected]>: 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 <[email protected]> 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 >> _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
