Re: [squeak-dev] Re: Menu Registries
Locked
12
12
Re: [squeak-dev] Re: Menu Registries
 
|
Hi all,+
Could those in the know comment on how this <...> proposal is (or is not) consistent with the fundamental Smalltalk principles 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 4/28/10, Brent Pinkney <[hidden email]> wrote:
> Hi all,+ > > Could those in the know comment on how this <...> proposal is (or is not) > consistent with the fundamental Smalltalk principles > 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 ? just not aware of it. If so, IMO we need to really get it > right before we commit. Yes, I agree. And this discussion is on-going. I'm glad you joined. In the writeup of Andreas Annotations for Service Discovery http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/ he uses the word 'orthogonal'. I think it is helpful to think of method annotations of something 'orthogonal' to regular Smalltalk source code. Like CSS is 'orthogonal' to HTML. --Hannes > Thanks > > Brent > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Brent Pinkney-2
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
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<[hidden email]>: 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 <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
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<[hidden email]>: > > 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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 4/28/10, Stéphane Ducasse <[hidden email]> wrote:
> 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 > Stéphane Thank you for your update on this issue. Do you have a link to writeup what the consensus for Pharo is regarding pragmas / method annotation / use of metadata? For which areas are they used? What are the conventions? For Squeak we do not necessarily want to do something different unless we think it is necessary because of shortcomings of your solutions (as perceived from our point of view). And I think the discussion on the Squeak list seems to develop into a direction where people want to get rid of the Preferences class like you. --Hannes _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
Like Steph implied, search the nabble archive, and you will find the
lengthy discussion which took place over a year ago. Cheers, Henry Den 28. apr. 2010 kl. 19.41 skrev Hannes Hirzel <[hidden email]>: > On 4/28/10, Stéphane Ducasse <[hidden email]> wrote: >> 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 >> > > Stéphane > > Thank you for your update on this issue. > Do you have a link to writeup what the consensus for Pharo is > regarding pragmas / method annotation / use of metadata? > > For which areas are they used? What are the conventions? For Squeak we > do not necessarily want to do something different unless we think it > is necessary because of shortcomings of your solutions (as perceived > from our point of view). > > And I think the discussion on the Squeak list seems to develop into a > direction where people want to get rid of the Preferences class like > you. > > --Hannes > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Brent Pinkney-2
On 28.04.2010 17:47, 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 > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > have your answer. The short answer is no, they just provide a different way of dynamically deciding what message you want to send. The closest equivalent would be the logic used to decide which ImageReadWriter subclass to actually use. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 4/28/10, Henrik Sperre Johansen <[hidden email]> wrote:
> On 28.04.2010 17:47, 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 >> that: >> >> 1. "an object is send a message and responds with an object" >> 2. there is no other "magic" in the system. >> > Take 15 mins to read the code dealing with Pragma preferences, and you'd > have your answer. > The short answer is no, they just provide a different way of dynamically > deciding what message you want to send. > The closest equivalent would be the logic used to decide which > ImageReadWriter subclass to actually use. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Henry I took your piece of advice of using 15 minutes to check out what Pharo pragma/method annotation wise and below is what I discovered. You might want directly to jump to the end for 3 questions --Hannes OK, 15 minutes 1. I open the Pharo 1.0 One-click image and type 'Pragma' in the search browser. (Note: it is not pristine, I have loaded Pier2 into it) 2 .There are five classes which contain 'Pragma'. Only Pragma has a class comment. It is very similar to the one in Squeak 4.1. 3. In this comment I am offered to evaluate a) SystemNavigation default browseAllSelect: [:m| m pragmas notEmpty] and to browse all nonprimitive methods with pragmas evaluate b) SystemNavigation default browseAllSelect: [:m| m primitive isZero and: [m pragmas notEmpty]] a) gives me 971 methods with pragmas in it, b) 219 - these are the ones of interest - the non primitive ones 4) Looking at the 219 pragmas reveals the following examples a) Very frequent ones - they deal with configuration managment <version: '1.0-baseline'> <version: '2.0' imports: #('2.0-baseline')> b) The ones of interest for the current discussion <cleanup> <value: 'children' comment: 'Display immediate children of the current structure.'> <sanitize> <systemsettings> <lint: 'Unnecessary "= true"' rationale: 'Property can be nil I imagine' author: 'stephane.ducasse'> <ignoreForCoverage> 5) I realize that the ones in group 4b) are very few. I have not found any pragma yet related to the menu definition. 6) I decide to go search for 'World' I find the classes TheWorldMenu, TheWorldMenuProvider,TheWorldMenuMainDockingbar which are of interest. They all have class comments which is fine. In addition I find TheWorldMainDockingBar instance openDockingBar which I execute and to my suprise I realize that Pharo has as well a regular menu though with funny cartoon icons. The entries are however not worked out yet and this is probably the reason why it is not activated by default. 7) Looking at the menu construction code of TheWorldMenu and TheWorldMenuMainDockingbar I do not find anything interesting regarding pragmas. All is hard wired. 8) You wrote that you had the pragma discussion one year ago, so I was expecting something more to be in 1.0. Maybe I should have checked out 1.1 alpha? 9) As the 15 minutes are nearly over I start to use the time for some final questions. QUESTIONS A. The fact that you refer me to Google and the Nabble list to find out the result of your pragma discussion has to be read as - there is no such document yet. Is this correct? B. Is there a list of pragmas and how they are supposed to be used? C. How do you want to handle the menus with pragmas? (It seems that Pharo is not much further advanced in this area). _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On Apr 28, 2010, at 9:57 PM, Hannes Hirzel wrote: > > OK, 15 minutes > > 1. I open the Pharo 1.0 One-click image and type 'Pragma' in the search browser. > (Note: it is not pristine, I have loaded Pier2 into it) > Thie menu pragmas are not in 1.0, just 1.1. > 2 .There are five classes which contain 'Pragma'. > Only Pragma has a class comment. It is very similar to the one in Squeak 4.1. > Yes, we (Lukas and myself) added them to Squeak 3.9. > > 5) I realize that the ones in group 4b) are very few. I have not found > any pragma yet related to the menu definition. > This is only in 1.1UNSTABLE > QUESTIONS > A. The fact that you refer me to Google and the Nabble list to find > out the result of your pragma discussion has to be read as - there is > no such document yet. Is this correct? > Yes. We write lots of ducumentation, but that one not yet... > B. Is there a list of pragmas and how they are supposed to be used? > No. > C. How do you want to handle the menus with pragmas? (It seems that > Pharo is not much further advanced in this area). > For MessageNames, the definiton looks like this: menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'Message Names') parent: #Tools; action:[self openMessageNames]; icon: self taskbarIcon. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Hannes Hirzel
> 2 .There are five classes which contain 'Pragma'.
> Only Pragma has a class comment. It is very similar to the one in Squeak 4.1. Pragmas were forcibly added in Squeak 3.9 to catch up with the modern world. > 7) Looking at the menu construction code of TheWorldMenu and > TheWorldMenuMainDockingbar I do not find anything interesting > regarding pragmas. All is hard wired. Check out Pharo 1.1, this is where the setting and the menus are built using pragmas. > B. Is there a list of pragmas and how they are supposed to be used? Pragmas are not declared statically as this is the case in VisualWorks. A class that uses certain pragmas should document it of course, but similar to the way you can send any message and define any message you can define any pragma and search for any pragma. It's dynamic as with message sends. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Hannes Hirzel
Hannes Hirzel a écrit :
Hi Hannes Unfortunately you've took the wrong version :) SystemSettings and registrable menu are in 1.1. Please, take the core and browse again. I suggest you to first take a look at registrable menu implementation. only 2 classes : MenuRegistration and PragmaMenuBuilder. see also the class side of MenuRegistrationExample. The settings implementation is a little bit more complicated but only because of the UI. The setting browser and the setting declaration model are in System-Settings-* sys cat. (removable) The Setting-* sys categories contain all settings declaration (they are removable and do not depend on ANY other setting related package thanks to the builder pattern). They are declared in order to allow their browsing through the use of the SettingBrowser. Preferences are simply class variables which are declared locally where they are used (as in Squeak but without pragma) Pragma discovering for menu and settings makes use of PragmaCollector (see the class comment). I can explain more but please browse the code before. > QUESTIONS > A. The fact that you refer me to Google and the Nabble list to find > out the result of your pragma discussion has to be read as - there is > no such document yet. Is this correct? > a documentation about the setting framework in under construction. > B. Is there a list of pragmas and how they are supposed to be used? > <systemsettings> and <worldMenu> browse all senders to #systemsettings and to #worldMenu to find all settings and menu items declarations. > C. How do you want to handle the menus with pragmas? (It seems that > Pharo is not much further advanced in this area). > again, in 1.1, the world menu is fully dynamically built using pragma (the same implementation scheme as for settings is used). Cheers Alain > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Hannes Hirzel
On 28.04.2010 21:57, Hannes Hirzel wrote:
> On 4/28/10, Henrik Sperre Johansen<[hidden email]> wrote: >> On 28.04.2010 17:47, 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 >>> that: >>> >>> 1. "an object is send a message and responds with an object" >>> 2. there is no other "magic" in the system. >>> >> Take 15 mins to read the code dealing with Pragma preferences, and you'd >> have your answer. >> The short answer is no, they just provide a different way of dynamically >> deciding what message you want to send. >> The closest equivalent would be the logic used to decide which >> ImageReadWriter subclass to actually use. >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > Henry > > I took your piece of advice of using 15 minutes to check out what > Pharo pragma/method annotation wise and below is what I discovered. > You might want directly to jump to the end for 3 questions > > --Hannes > > OK, 15 minutes > > 1. *snip* > 8) were :( (The age of the discussion can tell you one more thing: 1.0 was in beta a looooooong time :) ) The 15 minutes were meant for understanding how using pragmas adds no magic (at least not in the Smalltalk sense). In: http://forum.world.st/Fix-2329-Default-MC-Directory-Setting-td2019559.html#a2020047 , I wrote exactly where to find the code dealing with pragma discovery in both Pharo 1.1 and Squeak 4.1. > C. How do you want to handle the menus with pragmas? (It seems that > Pharo is not much further advanced in this area). > They are handled exactly the same way Preferences is handled. A PragmaCollector is told to find pragmas with a specific keyword. (#systemsettings or #worldmenu respectively for Settings and the World menu (currently the only dynamic menu in Pharo 1.1). For the methods discovered, you then: - for preferences: Pass in a preference builder to the method, which can then construct its preferences. - for menus: Pass in a menu builder to the method, which can then construct the menu items it needs. To the argument "But a builder decoupled from the method provides resistance to further change!" I say: How is that different from any of the many methods currently expecting as argument an instance of a class in base? If the base classes does indeed change, what would you rather see happening? a) An MNU or deprecated warning when trying to invoke the (now) invalid code? b) The code simply not doing what you expect it to? (ie. not adding menu items etc.) Yes, in b) you can still import old code and run it with no errors. That does not necessarily mean it does what you wanted it to do though. Cheers, Henry PS. I actually like the Squeak preference pragma. In 99% of the cases, it is sufficient, and you can place it directly as metadata in an existing accessor method, rather than having to define a new method simply for defining a method whose only difference from 30 others is what variable it stores into and reads from. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
Henrik Sperre Johansen a écrit :
> > PS. I actually like the Squeak preference pragma. In 99% of the cases, > it is sufficient, and you can place it directly as metadata in an > existing accessor method, rather than having to define a new method > simply for defining a method whose only difference from 30 others is > what variable it stores into and reads from. no, a package can group all its setting declarations in one method. Alain > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 28.04.2010 23:39, Alain Plantec wrote:
> Henrik Sperre Johansen a écrit : >> >> PS. I actually like the Squeak preference pragma. In 99% of the >> cases, it is sufficient, and you can place it directly as metadata in >> an existing accessor method, rather than having to define a new >> method simply for defining a method whose only difference from 30 >> others is what variable it stores into and reads from. > no, a package can group all its setting declarations in one method. > Alain I know :) My point was rather the pragmas in Squeak are more closely coupled with the point it is actually defined, in that you defined the pragma itself in the accessor method for the variable, rather than having 1-N declarations in a single method, pointing to 1-N places where those settings values can actually be found. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 4/28/2010 2:44 PM, Henrik Sperre Johansen wrote:
> My point was rather the pragmas in Squeak are more closely coupled with > the point it is actually defined, in that you defined the pragma itself > in the accessor method for the variable, rather than having 1-N > declarations in a single method, pointing to 1-N places where those > settings values can actually be found. Right. The other advantage is that the simple "pragma" (which we've already established isn't a pragma at all) is trivial to support. Here is an implementation for Pharo, taking all of six methods (it would have been three methods if the Settings framework had been structured a little different :-) Oh, and as a free goodie you get the ability to browse the implementors of both, #systemsettings as well as #preference:category:description:type: if you're curious where and how these annotations are used. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
SqueakPrefs-ar.cs (2K)
Re: [squeak-dev] Re: Menu Registries
|
|
Good but what is your point?
That Setting is a cool framework. We knew it already :) That we could get other preferences than the ones we have? We also knew it but we decided to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. On Apr 29, 2010, at 8:03 AM, Andreas Raab wrote: > On 4/28/2010 2:44 PM, Henrik Sperre Johansen wrote: >> My point was rather the pragmas in Squeak are more closely coupled with >> the point it is actually defined, in that you defined the pragma itself >> in the accessor method for the variable, rather than having 1-N >> declarations in a single method, pointing to 1-N places where those >> settings values can actually be found. > > Right. The other advantage is that the simple "pragma" > (which we've already established isn't a pragma at all) I do not understand your sentence. That the name is bad and should be called annotation? Yes we know it since ages we followed VW naming. > is trivial to support. Here is an implementation for Pharo, taking all of six methods (it would have been three methods if the Settings framework had been structured a little different :-) > > Oh, and as a free goodie you get the ability to browse the implementors of both, #systemsettings as well as #preference:category:description:type: if you're curious where and how these annotations are used. > > Cheers, > - Andreas > <SqueakPrefs-ar.cs>_______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
On 4/28/2010 11:32 PM, Stéphane Ducasse wrote:
> Good but what is your point? Compatibility and simplicity. > That Setting is a cool framework. We knew it already :) That's where you're confused. You keep talking about "cool" and I keep talking about "simple". These two are not the same yet you keep confusing them. If we want to have a certain amount of compatibility between Squeak and Pharo the defining property needs to be simplicity, not coolness. I don't care about the Settings framework, after having looked at it I find it difficult to understand and to follow. Too much "coolness" if you will and a lack of simplicity. But that's my opinion. If you think Settings is cool, use it. I'm still interested in compatibility though, and as a consequence, I think we should agree on some basics. It's unlikely that anyone is going to implement the entire Pharo Settings framework in Squeak, so instead I'm giving you a trivial implementation of Squeak's preference annotation, along the way making a point about simplicity. > That we could get other preferences than the ones we have? We also knew it but we decided > to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. I'm not trying to "tell" you anything. I'm presenting to you the option to be compatible with Squeak regarding simple preferences by giving you an implementation for Pharo. It seems to me that this is the best way to ensure a level of compatibility. It's your choice to take it or leave it. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
Well
well well >> Good but what is your point? > > Compatibility and simplicity. do you want to tie us with strings on the temple of compatibility? We do not want that. We are sorry but we do not want to lose what we designed as it is what we need/want, just because squeak has a worse solution that you call compatible and simple. >> That Setting is a cool framework. We knew it alreaady :) > > That's where you're confused. You keep talking about "cool" and I keep talking about "simple". These two are not the same yet you keep confusing them. You know me and my english sometimes I'm easily confused. > If we want to have a certain amount of compatibility between Squeak and Pharo the defining property needs to be simplicity, not coolness. I don't care about the Settings framework, after having looked at it I find it difficult to understand and to follow. Too much "coolness" if you will and a lack of simplicity. But that's my opinion. If you think Settings is cool, use it. thanks for your permission. > I'm still interested in compatibility though, and as a consequence, I think we should agree on some basics. It's unlikely that anyone is going to implement the entire Pharo Settings framework in Squeak, so instead I'm giving you a trivial implementation of Squeak's preference annotation, along the way making a point about simplicity. yes but what can we do with it? Since it does not fit our needs. >> That we could get other preferences than the ones we have? We also knew it but we decided >> to go for a no argument pragma. So I'm a little bit confused but what you try to tell us. > > I'm not trying to "tell" you anything. I'm presenting to you the option to be compatible with Squeak regarding simple preferences by giving you an implementation for Pharo. It seems to me that this is the best way to ensure a level of compatibility. It's your choice to take it or leave it. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Menu Registries
|
|
In reply to this post by Andreas.Raab
Andreas Raab a écrit :
> On 4/28/2010 11:32 PM, Stéphane Ducasse wrote: >> Good but what is your point? > > Compatibility and simplicity. Come on Andreas, "simple" is not so much more precise than "cool" and I don't think that having: ------------------ Editor class>>blinkingCursor ^ BlinkingCursor ifNil: [ true ] EditorSetting class>>editorSettingsOn: aBuilder <systemsettings> (aBuilder setting: #blinkingCursor) label:'Blinking Text Cursor') parent: #Morphic; target: Editor; description: 'When true, the text cursor will blink.' ------------------- is so much more "complicated" than ------------------- Editor class>>blinkingCursor <preference: 'Blinking Text Cursor' category: 'Morphic' description: 'When true, the text cursor will blink.' type: #Boolean> ^ BlinkingCursor ifNil: [ true ] ------------------- You prefer UI+domain mixing, we prefer UI separated from domain. And yes, the SettingBrowser implementation could be improved. I know, but I'm happy because it can be removed or remade without any other consequence. And compare it to the PreferenceBrowser ... Cheers Alain _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |