Hannes We know pragmas since they appeared a while ago in VW. We are good metaprogrammers and know that annotation are good to a certain extent: I do not like the delegate annotation used by vassily in VW because they changed the semantics of the system.
Now we got lengthy discussion a while ago in the pharo mailing-list and may be in the squeak one since I remember andreas presenting his view. We reached a consensus, alain changed his implementation to fit the result of the discussions and we are quite happy with it. - We can package setting in a package or outside (outside is better since we do not have dead code) when preferences are not loaded, but this is the choice of the package designer. - We use a builder so that we do not have to have a mini language interpreter for the pragmas. As I said we are happy with it and we hope to get rid of Preferences completely :). Stef > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
