Re: [Pharo-project] [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
On 4/28/10, Brent Pinkney <brent@zamail.co.za> 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 ? YES, actually it has already happened. You like me one week ago were 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-disco... 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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-disco... 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@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-disco... Cheers, - Andreas On 4/28/10, Stéphane Ducasse <stephane.ducasse@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
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-disco...
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@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-disco...
Cheers, - Andreas
On 4/28/10, Stéphane Ducasse <stephane.ducasse@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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 4/28/10, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
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 <hannes.hirzel@gmail.com>:
On 4/28/10, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On 4/28/10, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> 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 Pharo-project@lists.gforge.inria.fr 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).
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.
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 28.04.2010 21:57, Hannes Hirzel wrote:
On 4/28/10, Henrik Sperre Johansen<henrik.s.johansen@veloxit.no> 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 Pharo-project@lists.gforge.inria.fr 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) Yes, sorry I didn't specify which images, I assumed you knew where they 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#a... , 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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
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.
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the
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.
It does not fit all the needs, no. - Sub-categories: Not impossible, but still; not supported. - Advanced value types: Specific strings like passwords, filenames, radio-button type prefs, integers with ranges, etc. - Precondition: etc. are not supported. In Pharo, there are - 86 Settings (if I counted correctly, there could be some preconditional ones I didn't see as well). - 23 Could be implemented Squeak-pragma style currently. - 63 if sub-categories were supported. The remaining 23 are split: - chooses fonts (8) - conditional. (7) - multiple choice prefs whose possible values which can't be linked directly to type: by the builder (5) - have ranges to their possible values (4) - Chooses files (1) - Chooses password (1). So no, the pragma/annotation don't fit our needs exactly. (For that matter, neither does it fit the needs of all preferences in Squeak) If support for sub-categories was added, a lot of them could be written in the simpler squeak style though, with no loss of functionality. IMO, providing support for both (if a way to specify sub-categories were decided upon) would match up well with the mantra: 'Make the common things easy; make the hard things possible'. Cheers, Henry PS. Multival could be supported in squeak with a type: #Choice or something, and an additional pragma somewhat like: <preferenceChoiceFor: 'UI Theme' label: 'Aqua 2'>
Henrik Johansen a écrit :
On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the
the upside is ... :) well, I will have a look at the cs. I would prefer that this changes do not introduce any overwriting so that it can be loaded separately as a compatibility package. so, i will investigate the changes needed for the settingbrowser. is that ok like that ? Cheers Alain
On Apr 29, 2010, at 1:44 29PM, Alain Plantec wrote:
Henrik Johansen a écrit :
On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the the upside is ... :) well, I will have a look at the cs. I would prefer that this changes do not introduce any overwriting so that it can be loaded separately as a compatibility package. so, i will investigate the changes needed for the settingbrowser. is that ok like that ? Cheers Alain
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P Cheers, Henry
Henrik Johansen a écrit :
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
:) I've checked and only two methods has to be adapted and one added in Pharo. Then a compatibility package can be implemented for Squeak. This package is optional and could be available for pharo-dev. I will provide it soon. Alain
Cheers, Henry
excellent! On Apr 29, 2010, at 4:16 PM, Alain Plantec wrote:
Henrik Johansen a écrit :
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
:) I've checked and only two methods has to be adapted and one added in Pharo. Then a compatibility package can be implemented for Squeak. This package is optional and could be available for pharo-dev. I will provide it soon. Alain
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Alain Plantec a écrit :
Henrik Johansen a écrit :
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
:) I've checked and only two methods has to be adapted and one added in Pharo. Then a compatibility package can be implemented for Squeak. This package is optional and could be available for pharo-dev. I will provide it soon. Alain SLICE-SystemSettings-SqueakCompatibility is in the InBox. The SqueakPreferences package is attached. Henrik, can you check and put it somewhere for pharo-dev ?
For now, It only contains the following method: ---------------- SettingTreeBuilder>>preference: prefName category: category description: description type: type <settingPragmaProcessor> "Process a Squeak preference pragma" .... ---------------- It is tagged by the #settingPragmaProcessor pragma which is used by the builder when a SettingBrowser is opened in order to retrieve current settings keywords. For Pharo settings, the following is implemented ---------------- SettingTreeBuilder>>systemsettings <settingPragmaProcessor> "Process a <systemsettings> pragma" currentPragma methodClass theNonMetaClass perform: currentPragma selector with: self. ---------------- So, if Squeak makes use of a new pragma, the only thing to do is to add a similar method in the SqueakPreferences package and tag it with a #settingPragmaProcessor pragma. thanks to Andreas for its cs, I've removed one method and changed another one. Cheers Alain
Cheers, Henry
http://code.google.com/p/pharo/issues/detail?id=2370 Alain Plantec a écrit :
Alain Plantec a écrit :
Henrik Johansen a écrit :
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
:) I've checked and only two methods has to be adapted and one added in Pharo. Then a compatibility package can be implemented for Squeak. This package is optional and could be available for pharo-dev. I will provide it soon. Alain SLICE-SystemSettings-SqueakCompatibility is in the InBox. The SqueakPreferences package is attached. Henrik, can you check and put it somewhere for pharo-dev ?
For now, It only contains the following method: ---------------- SettingTreeBuilder>>preference: prefName category: category description: description type: type <settingPragmaProcessor> "Process a Squeak preference pragma" .... ---------------- It is tagged by the #settingPragmaProcessor pragma which is used by the builder when a SettingBrowser is opened in order to retrieve current settings keywords.
For Pharo settings, the following is implemented ---------------- SettingTreeBuilder>>systemsettings <settingPragmaProcessor> "Process a <systemsettings> pragma" currentPragma methodClass theNonMetaClass perform: currentPragma selector with: self. ----------------
So, if Squeak makes use of a new pragma, the only thing to do is to add a similar method in the SqueakPreferences package and tag it with a #settingPragmaProcessor pragma.
thanks to Andreas for its cs, I've removed one method and changed another one.
Cheers Alain
Cheers, Henry
Thanks! I'll make sure to look at it when I get home. Cheers, Henry Den 29. apr. 2010 kl. 19.26 skrev Alain Plantec <alain.plantec@free.fr>:
http://code.google.com/p/pharo/issues/detail?id=2370
Alain Plantec a écrit :
Alain Plantec a écrit :
Henrik Johansen a écrit :
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
:) I've checked and only two methods has to be adapted and one added in Pharo. Then a compatibility package can be implemented for Squeak. This package is optional and could be available for pharo-dev. I will provide it soon. Alain SLICE-SystemSettings-SqueakCompatibility is in the InBox. The SqueakPreferences package is attached. Henrik, can you check and put it somewhere for pharo-dev ?
For now, It only contains the following method: ---------------- SettingTreeBuilder>>preference: prefName category: category description: description type: type <settingPragmaProcessor> "Process a Squeak preference pragma" .... ---------------- It is tagged by the #settingPragmaProcessor pragma which is used by the builder when a SettingBrowser is opened in order to retrieve current settings keywords.
For Pharo settings, the following is implemented ---------------- SettingTreeBuilder>>systemsettings <settingPragmaProcessor> "Process a <systemsettings> pragma" currentPragma methodClass theNonMetaClass perform: currentPragma selector with: self. ----------------
So, if Squeak makes use of a new pragma, the only thing to do is to add a similar method in the SqueakPreferences package and tag it with a #settingPragmaProcessor pragma.
thanks to Andreas for its cs, I've removed one method and changed another one.
Cheers Alain
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Apr 29, 2010 at 4:53 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On Apr 29, 2010, at 1:44 29PM, Alain Plantec wrote:
Henrik Johansen a écrit :
On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the the upside is ... :) well, I will have a look at the cs. I would prefer that this changes do not introduce any overwriting so that it can be loaded separately as a compatibility package. so, i will investigate the changes needed for the settingbrowser. is that ok like that ? Cheers Alain
It needs a way to register new valid preference pragmas, and setting generators for such pragmas. May I suggest... using pragmas? ;P
This ids the way it works (and has worked for nearly 10 years) in VisualWorks. On the class side one can declare the pragmas a class supports using pragmas. One uses pragmas to avoid having one method that defines all pragmas for a class, which would create a potential conflict between packages of the kind that pragmas help avoid. When the compiler encounters a pragma it searches the class side looking for the pragmas that are "in scope" at the moment. The argument to the pragma: pragma is a symbol stating which side of the class the pragma is valid (why they don't support #both or #(class instance) I don't know). Here are some examples: AboutVisualWorksPage class methods for private pagePragma <pragmas: #class> ^#(pageOrder:) systemPragma <pragmas: #class> ^#(systemInformation:) BlockClosure class methods for private exceptionPragmas <pragmas: #instance> ^#(#exception:) StandardSystemController class methods for resources menuMethodPragmas <pragmas: #instance> <pragmas: #class> ^Menu pragmas With this approach a package can add its own method annotations to a hierarchy without conflicting with any other package. Here's the VW code that fetches the pragmas understood by a class: Metaclass methods for compiling recognizedMethodPragmas ^self soleInstance recognizedMethodPragmas: #class Class methods for compiling recognizedMethodPragmas ^self recognizedMethodPragmas: #instance requiredRecognizedPragmas ^#(#pragmas: #primitive: #primitive:errorCode:) recognizedMethodPragmas: type "The 'type' argument may be either #class or #instance" | list beh | list := IdentitySet withAll: self requiredRecognizedPragmas. beh := self class. [beh isMeta] whileTrue: [beh selectorsAndMethodsDo: [:sel :meth | | pragmas | pragmas := meth attributeMessages. pragmas == nil ifFalse: [pragmas do: [:msg | (msg selector = #pragmas: and: [msg arguments first = type]) ifTrue: [list addAll: (beh soleInstance perform: sel)]]]]. beh := beh superclass]. ^list Simple, but fabulously meta. Thank Steve Dahl for this idea. Cheers,
Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes sounds good. Prove that 3 methods are enough because we are cool :)
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the the upside is ... :) well, I will have a look at the cs. I would prefer that this changes do not introduce any overwriting so that it can be loaded separately as a compatibility package. so, i will investigate the changes needed for the settingbrowser. is that ok like that ? Cheers Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok I see and I like your analysis. This is much more positive energy :) so what we could do is to integrate the code of andreas but write in big that we should not use it internally. Tell me if I interpreted well your message :) Stef
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.
It's not a question of one vs. the other, really. The cs doesn't change the Settings implementation, it simply adds support for also discovering settings defined in the pragma style used by Squeak. The downside is you'd have two ways to define settings. The upside is the
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.
It does not fit all the needs, no. - Sub-categories: Not impossible, but still; not supported. - Advanced value types: Specific strings like passwords, filenames, radio-button type prefs, integers with ranges, etc. - Precondition: etc. are not supported.
In Pharo, there are - 86 Settings (if I counted correctly, there could be some preconditional ones I didn't see as well). - 23 Could be implemented Squeak-pragma style currently. - 63 if sub-categories were supported. The remaining 23 are split: - chooses fonts (8) - conditional. (7) - multiple choice prefs whose possible values which can't be linked directly to type: by the builder (5) - have ranges to their possible values (4) - Chooses files (1) - Chooses password (1).
So no, the pragma/annotation don't fit our needs exactly. (For that matter, neither does it fit the needs of all preferences in Squeak) If support for sub-categories was added, a lot of them could be written in the simpler squeak style though, with no loss of functionality.
IMO, providing support for both (if a way to specify sub-categories were decided upon) would match up well with the mantra: 'Make the common things easy; make the hard things possible'.
Cheers, Henry
PS. Multival could be supported in squeak with a type: #Choice or something, and an additional pragma somewhat like: <preferenceChoiceFor: 'UI Theme' label: 'Aqua 2'>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
+1 So now we will be the guys that do not want to be backward compatible, but this is on the web page of pharo so nothing really new to me :)
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 29, 2010, at 12:46 17PM, Stéphane Ducasse wrote:
+1
So now we will be the guys that do not want to be backward compatible
Can't really claim that when neither approach is used in any existing released images ;) Cheers, Henry
I have to say that devolving any technical discussion into "you think this..." and "we think that..." is a very quick way to destroy any ability to think critically in a technical discussion. This isn't Andreas "liking" anything, this is the result of having thought critically and objectively about the issues. Can we please act like engineers and scientists ought? Substantive comments below. On Thu, Apr 29, 2010 at 3:21 AM, Alain Plantec <alain.plantec@free.fr>wrote:
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 ] -------------------
Well the former is executable and must be executable. The latter is not necessarily executable (but its good if it is, because one can locate the code that processes the specification) . So they're the same on that level. But the former can only be executable and isn't separated from the processing code, whereas the latter is separated. The former also only works in context (aBuilder) whereas the latter stands alone, and this ability to stand alone, as a specification, loosely coupled to the settings maintennance system is one thing that makes it simpler. It also clearly states the default value which the former doesn't. So I find the latter significantly easier to understand, and given I understand the method annotation system I find the mechanics not that much more complicated than the former's. We all understand perform: right?
You prefer UI+domain mixing, we prefer UI separated from domain.
I see the opposite. I see good separation in the latter example but I don't see the separation in the former. And BTW this is me trying to think critically, trying to keep happy feet in both the Pharo and Squeak (and eToys and Cuis and ....) camps, not trying to be tribal. Apologies in advance if expressing a contradictory view is taken as offensive.
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
best Eliot
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1. This is close to what I intended to write after "on the positive", but forgot :) (probably better than I would have, though) Cheers, Henry Den 29. apr. 2010 kl. 19.40 skrev Eliot Miranda <eliot.miranda@gmail.com>:
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 ] -------------------
Well the former is executable and must be executable. The latter is not necessarily executable (but its good if it is, because one can locate the code that processes the specification) . So they're the same on that level. But the former can only be executable and isn't separated from the processing code, whereas the latter is separated. The former also only works in context (aBuilder) whereas the latter stands alone, and this ability to stand alone, as a specification, loosely coupled to the settings maintennance system is one thing that makes it simpler. It also clearly states the default value which the former doesn't. So I find the latter significantly easier to understand, and given I understand the method annotation system I find the mechanics not that much more complicated than the former's. We all understand perform: right?
You prefer UI+domain mixing, we prefer UI separated from domain.
I see the opposite. I see good separation in the latter example but I don't see the separation in the former. And BTW this is me trying to think critically, trying to keep happy feet in both the Pharo and Squeak (and eToys and Cuis and ....) camps, not trying to be tribal. Apologies in advance if expressing a contradictory view is taken as offensive.
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
best Eliot
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 ] -------------------
Well the former is executable and must be executable. The latter is not necessarily executable (but its good if it is, because one can locate the code that processes the specification) . So they're the same on that level. But the former can only be executable and isn't separated from the processing code, whereas the latter is separated.
Yes this is clear we got that discussion long time ago and we are aware of the pros and the cons. At least as a language designer expert this is obvious to me. Now I do not want to argue again. The goal of setting is to have settings totally out of the code and only make sense in presence of an interpreter of them. So...
The former also only works in context (aBuilder) whereas the latter stands alone, and this ability to stand alone, as a specification, loosely coupled to the settings maintennance system is one thing that makes it simpler. It also clearly states the default value which the former doesn't. So I find the latter significantly easier to understand, and given I understand the method annotation system I find the mechanics not that much more complicated than the former's. We all understand perform: right?
Yes now the key dimension is whether your vocabulary is fixed or not. When you have a fixed vocabulary then this is clear that the declarative syntax is the winner and the other one does not make sense. But for preferences it does not work. or you should have a much more lengthly key and interpret the arguments.
You prefer UI+domain mixing, we prefer UI separated from domain.
I see the opposite. I see good separation in the latter example but I don't see the separation in the former. And BTW this is me trying to think critically, trying to keep happy feet in both the Pharo and Squeak (and eToys and Cuis and ....) camps, not trying to be tribal. Apologies in advance if expressing a contradictory view is taken as offensive.
I will not add more. I think that we should favor declarative syntax as much as we can but not more. Stef
On 4/29/2010 3:21 AM, Alain Plantec wrote:
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"
That comment deserves a more detailed exploration than I want to put into this message. You can find my response here: http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/
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're right, by itself it may not be "so much more complicated". But isn't this forgetting a few things? Like for example, that not only are you adding the extra method, but also an extra class and an extra package? This gets you from a single entity (the domain code) to four entities (the domain code, the builder method, class and package). In terms of both conceptual and interface simplicity that seems significant (and a dozen of messages in the builder all add to interface complexity). BTW, I want to point out something important here. I'm not saying your approach is "bad". Good and bad, black and white, are not categories that I use for evaluating software design. I leave that to the people with overly simplified views on software development ;-) There are only different trade-offs for different goals. Your approach is perfectly reasonable for a given set of goals and trade-offs. If there is a need to have specific fine-grained control over the UI to particular preferences, I would choose precisely the same approach - make a package with views for the values that I want to modify. It's a perfectly fine approach for such a set of goals. Moreover, "simplicity" isn't an absolute attribute of software. Simplicity is a tradeoff. It is often worthwhile to trade off simplicity, for example when adding valuable new features. So my claim here is not about "good" and "bad". My claim is this: 1. The approach in Squeak is measurably simpler than yours. It may not fit your goals, you may need a different approach, that's quite possible. But there are numbers we can put on things to compare them and if we put the numbers on then Squeak's approach is simpler. 2. Because of the difference in interface complexity, I expect Squeak's approach will be easier to support in the long term. There's no proof for that, but I think the claim is valid, and I will watch the future developments in both Pharo and Squeak with interest. 3. Your initial design choice of using a builder framework for preferences implied the later complexity. Because the approach requires adding non-domain code to core classes it creates pressure to put this code elsewhere and to package that code separately. It's a valuable lesson about the impact of early design choices.
You prefer UI+domain mixing, we prefer UI separated from domain.
I'm missing something. What UI+domain mixing? There is no UI code in Squeak's preference tags. There is only domain code and a method tag for discovery of the preference. Only Pharo has UI (builder) code; there is no equivalent in Squeak's preference tags.
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 ...
I'm not certain what your point here is. I'm only talking about preference declaration, not about how the preference browser functions. PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the packages that I customarily unload for creating smaller images, because I'm quite happy to set my preferences by sending message to objects directly :-) Cheers, - Andreas
participants (10)
-
Alain Plantec -
Andreas Raab -
Brent Pinkney -
Eliot Miranda -
Hannes Hirzel -
Henrik Johansen -
Henrik Sperre Johansen
-
Lukas Renggli -
Marcus Denker -
Stéphane Ducasse