[Squeak-dev] World Menu Registry

> On 4/27/10, Nicolas Cellier <[hidden email]> wrote:
>> 2010/4/27 Sean P. DeNigris <[hidden email]>:
>>>
>>> I will post replies I get in pharo-project here as a resource in this
>>> conversation:
>>>
>>> Pharo menus can have pre-condition blocks:
>>> Hi Sean,
>>> you can declare a menu item with a precondition block.
>>> the menu item is not added to the menu if the precondition is false.
>>> We have one example in the core. See the precondition in the #'Software
>>> update' item.
>>>
>>> WorldState class>>systemOn: aBuilder
>>>    <worldMenu>
>>>    (aBuilder item: #System)
>>>        order: 4.0;
>>>        withSeparatorAfter;
>>>        icon: MenuIcons smallConfigurationIcon;
>>>        with: [
>>>            (aBuilder item: #'About...')
>>>                order: 0;
>>>                action: [Smalltalk aboutThisSystem].
>>>            (aBuilder item: #'Software update')
>>>                order: 1;
>>>                precondition: [self showUpdateOptionInWorldMenu];
>>>                action: [Utilities updateFromServer];
>>>                help: 'Load latest code updates via the internet']
>>>
>>> A take on the pros and cons of existing preference style v.s. Pharo menu
>>> style:
>>> Comparing Settings to Preference Annotations might gleam at the difference
>>> you might expect between menu annotations in Pharo and Squeak.
>>>
>>> In Pharo the method contains a simple annotation with no args, and the
>>> method contains code for building a menuitem using the builder passed as
>>> argument,
>>> My speculation: If following the existing preference-style, Squeak will
>>> probably use an annotation with more args, with the method body containing
>>> the actual action.
>>> i.e. Alains example would be written something like:
>>> WorldState class>>aboutMenuItem
>>> <menuItemIn: #('WorldMenu' 'System')
>>>        order: 0
>>>        label: 'About... '>
>>> Smalltalk aboutThisSystem
>>>
>>> WorldState>>updateFromServertMenuItem
>>> <menuItemIn: #('WorldMenu' 'System')
>>>        order: 1
>>>        label: 'About... '
>>>        visible: #showUpdateOptionInWorldMenu
>>>        help: 'Load latest code updates via the internet'>
>>> Utilites updateFromServer
>>>
>>>
>>> Both approaches have their pros and cons.
>>> The one in Pharo depends on a builder responding to certain messages, so
>>> expanding the API might lead to breakage if you try to load into an old
>>> image.
>>> You also have to define new annotation keywords for each menu you want to
>>> build this way, .
>>>
>>> The one for Squeak might suffer a risk of needing a large amount of
>>> permutations of annotations  , depending on which PluggableMenuItemSpec
>>> properties you'd want to be able to leave optional.
>>>
>>
>> Would it be possible to use known techniques like cascading?
>> <menuItemIn: #('WorldMenu' 'System');
>>         order: 1;
>>         label: 'About... ';
>>         visible: #showUpdateOptionInWorldMenu;
>>         help: 'Load latest code updates via the internet'>
>> The idea would be to send messages to a Builder.
>> The builder would have a current target (created by #menuItemIn:) to
>> which subsequent messages would be sent...
>> Not sure at all cascading is allowed now, but it eventually could.
>>
>>> In short: In Pharo you have access to the builder in the method, while in
>>> Squeak (based on how Preferences annotations work) I'd expect they end up
>>> with a builder parsing an annotation instead.
>>>
>>
>> My first impression is that while Pharo is reacher, it is also weaker
>> w.r.t. core system evolutions because exposing more API.
>> The difference is subtle though, because my above cascade example is
>> also exposing an API...
>> But it is different : we don't have to just execute the cascade, we
>> could catch and ignore every not-understood message, and proceed with
>> the next one...
>> ... or we could also preprocess and transform the messages etc...
>>
>> One advantage of Pharo is the possibility to insert a halt in the
>> constructing phase, but hey, we could place a halt: in the cascade
>> too...
>> Pharo solution also gives reflection on the builder, which is
>> powerfull, the pragma/annotation does not.
>>
>> If we can't agree though, the nice thing with pragmas/annotations is
>> that both menu declaration can co-exist (as long as keyword don't
>> conflict).
>> Package developpers would have to provide two hooks, and code critics
>> might complain of some missing API, but that's not a drama.
>>
>> Nicolas
>>
>>> --
>>> View this message in context:
>>> http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>

> 2010/4/27 Hannes Hirzel <[hidden email]>:
>> What are the reasons for not going for the Pharo solution?
>>
>> --Hannes
>>
>
> 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.
>
> Nicolas
>
>> On 4/27/10, Nicolas Cellier <[hidden email]> wrote:
>>> 2010/4/27 Sean P. DeNigris <[hidden email]>:
>>>>
>>>> I will post replies I get in pharo-project here as a resource in this
>>>> conversation:
>>>>
>>>> Pharo menus can have pre-condition blocks:
>>>> Hi Sean,
>>>> you can declare a menu item with a precondition block.
>>>> the menu item is not added to the menu if the precondition is false.
>>>> We have one example in the core. See the precondition in the #'Software
>>>> update' item.
>>>>
>>>> WorldState class>>systemOn: aBuilder
>>>>    <worldMenu>
>>>>    (aBuilder item: #System)
>>>>        order: 4.0;
>>>>        withSeparatorAfter;
>>>>        icon: MenuIcons smallConfigurationIcon;
>>>>        with: [
>>>>            (aBuilder item: #'About...')
>>>>                order: 0;
>>>>                action: [Smalltalk aboutThisSystem].
>>>>            (aBuilder item: #'Software update')
>>>>                order: 1;
>>>>                precondition: [self showUpdateOptionInWorldMenu];
>>>>                action: [Utilities updateFromServer];
>>>>                help: 'Load latest code updates via the internet']
>>>>
>>>> A take on the pros and cons of existing preference style v.s. Pharo menu
>>>> style:
>>>> Comparing Settings to Preference Annotations might gleam at the difference
>>>> you might expect between menu annotations in Pharo and Squeak.
>>>>
>>>> In Pharo the method contains a simple annotation with no args, and the
>>>> method contains code for building a menuitem using the builder passed as
>>>> argument,
>>>> My speculation: If following the existing preference-style, Squeak will
>>>> probably use an annotation with more args, with the method body containing
>>>> the actual action.
>>>> i.e. Alains example would be written something like:
>>>> WorldState class>>aboutMenuItem
>>>> <menuItemIn: #('WorldMenu' 'System')
>>>>        order: 0
>>>>        label: 'About... '>
>>>> Smalltalk aboutThisSystem
>>>>
>>>> WorldState>>updateFromServertMenuItem
>>>> <menuItemIn: #('WorldMenu' 'System')
>>>>        order: 1
>>>>        label: 'About... '
>>>>        visible: #showUpdateOptionInWorldMenu
>>>>        help: 'Load latest code updates via the internet'>
>>>> Utilites updateFromServer
>>>>
>>>>
>>>> Both approaches have their pros and cons.
>>>> The one in Pharo depends on a builder responding to certain messages, so
>>>> expanding the API might lead to breakage if you try to load into an old
>>>> image.
>>>> You also have to define new annotation keywords for each menu you want to
>>>> build this way, .
>>>>
>>>> The one for Squeak might suffer a risk of needing a large amount of
>>>> permutations of annotations  , depending on which PluggableMenuItemSpec
>>>> properties you'd want to be able to leave optional.
>>>>
>>>
>>> Would it be possible to use known techniques like cascading?
>>> <menuItemIn: #('WorldMenu' 'System');
>>>         order: 1;
>>>         label: 'About... ';
>>>         visible: #showUpdateOptionInWorldMenu;
>>>         help: 'Load latest code updates via the internet'>
>>> The idea would be to send messages to a Builder.
>>> The builder would have a current target (created by #menuItemIn:) to
>>> which subsequent messages would be sent...
>>> Not sure at all cascading is allowed now, but it eventually could.
>>>
>>>> In short: In Pharo you have access to the builder in the method, while in
>>>> Squeak (based on how Preferences annotations work) I'd expect they end up
>>>> with a builder parsing an annotation instead.
>>>>
>>>
>>> My first impression is that while Pharo is reacher, it is also weaker
>>> w.r.t. core system evolutions because exposing more API.
>>> The difference is subtle though, because my above cascade example is
>>> also exposing an API...
>>> But it is different : we don't have to just execute the cascade, we
>>> could catch and ignore every not-understood message, and proceed with
>>> the next one...
>>> ... or we could also preprocess and transform the messages etc...
>>>
>>> One advantage of Pharo is the possibility to insert a halt in the
>>> constructing phase, but hey, we could place a halt: in the cascade
>>> too...
>>> Pharo solution also gives reflection on the builder, which is
>>> powerfull, the pragma/annotation does not.
>>>
>>> If we can't agree though, the nice thing with pragmas/annotations is
>>> that both menu declaration can co-exist (as long as keyword don't
>>> conflict).
>>> Package developpers would have to provide two hooks, and code critics
>>> might complain of some missing API, but that's not a drama.
>>>
>>> Nicolas
>>>
>>>> --
>>>> View this message in context:
>>>> http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html
>>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>
>>
>

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

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

> Am 28.04.2010 12:26, schrieb Hannes Hirzel:
>> Thank you Andreas for the writeup you put at
>>
>> 'Annotations for Service Discovery'
>> http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/
>> [...]
>>
>> --Hannes
> +1
>
> Thank you all (on- and off-list) for the pragma discussion. Now I see
> that pragmas can be looked at from different angles. I believe what we
> want for menus is a pragma which is like a declarative contract (see
> Tobias' post).
>
> What about organizing official system extension points via services?
> A (DockingBar-)MenuBuilder is a service, a PreferenceManager is a
> service, ..and so on.
>
> Given I have build an applications that wants to use a menu service it
> could implement something along this:
>
> toggleColor
> "Toggles the background color of my singleton instance."
> <action>
> <actionScope: #UI>
> <actionCategory: #extra subCategory: #colors>
> <actionOccurence: #persistent>
> <actionName: 'Toggle Color'>
> <actionIcon: #toggleColorIcon>
>
> (Instance color = Color blue)
> ifTrue: [ Instance color: Color red ]
> ifFalse: [ Instance color: Color blue ].
>
> Please read the method like this:
>  This message wants to contribute an action which should be accessible
> through the UI - therefore we have the annotation <action> (which is
> kind of a general tag) and <actionScope: #UI> which says we want this
> action be present in the UI.
> (The other annotations are optional in this case!)
>
> Pleasee note that the message basically implements its own business
> stuff, but annotates some ui-things as a different plane.
>
> The DockingBar, for example, is a way to represent UI-actions which
> applications offer the user.
> So a service, namely the docking bar, looks through all
> service-annotations with scope: #UI. ("Ah, I (the docking bar) may offer
> a menu for this message of this class").
> As it is specified that this is a persistent activity (meaning: this
> UIAction doesn't change too often) through <serviceOccurence:
> #persistent> the docking bar decides to build a menu for this action.
> (The world menu may decide different as it is better in displaying
> #changing actions.)
>
> What do you think about this approach?
>
> - philipp
>
>

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

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

> OK, Andreas was faster than me....
>
> He says that the annotation scheme is perfectly consistent with
>
>    1. "an object is send a message and responds with an object"
>
> Could this please be elaborated a bit
>
> --Hannes
>

>
> On 4/28/10, Hannes Hirzel <[hidden email]> wrote:
>> 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 ?
>> 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-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
>>>
>>>
>>
>
>

>
> On 4/28/2010 8:47 AM, 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"
>
> It is perfectly consistent with it.
>
>> 2. there is no other "magic" in the system.
>
> Did you make that up? A wise man once said that any sufficiently advanced technology is indistinguishable from magic. I don't recall this ever being mentioned as a "fundamental principle" of Smalltalk.
>
>> Are we proposing a break fromv this ? If so, IMO we need to really get it right before we commit.
>
> Nobody is proposing to break with the first. I don't know what constitutes "magic" to answer the second but I'll point out that reflection has generally been accepted as a tool in the Smalltalk community although it could be considered magic.
>
> Cheers,
>  - Andreas

>>> 1. "an object is send a message and responds with an object"
>> It is perfectly consistent with it.
>
> On reading your blog, I think I can grog that: some interrogation message is sent to the class/method and it replies with the
> pragma thing or similar.
>
>>> 2. there is no other "magic" in the system.
>>> Did you make that up? A wise man once said that any sufficiently
>> advanced technology is indistinguishable from magic. I don't recall this
>> ever being mentioned as a "fundamental principle" of Smalltalk.
>
> This was not meant to be confrontational, sorry if it came across as such.

> By way of example, I think the general dislike for the
> current compiled method format with its byte code trailer is evidence that we as a community do not like solutions that are
> special and work with unseen code (magic) in the VM.
>
> I am just trying to ensure that what we get is a breakthrough solution that can also motivated from our communities shared
> aesthetics, which I tried to summarise as above.
>
> If so, then cool.
>
> Cheers
>
> 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
>>

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

> Folks, *please* change the subject according to the discussion topic. Srsly.
>
> On 28.04.2010, at 17:57, Andreas Raab wrote:
>>
>> On 4/28/2010 8:47 AM, 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"
>>
>> It is perfectly consistent with it.
>>
>>> 2. there is no other "magic" in the system.
>>
>> Did you make that up? A wise man once said that any sufficiently advanced technology is indistinguishable from magic. I don't recall this ever being mentioned as a "fundamental principle" of Smalltalk.
>>
>>> Are we proposing a break fromv this ? If so, IMO we need to really get it right before we commit.
>>
>> Nobody is proposing to break with the first. I don't know what constitutes "magic" to answer the second but I'll point out that reflection has generally been accepted as a tool in the Smalltalk community although it could be considered magic.
>>
>> Cheers,
>>  - Andreas
>
> IMHO there is a tendency even in the Smalltalk community towards working more with code, less with objects. What method properties do could as well be represented differently, and edited with some other UI than text. But we still do not have an accepted way to share objects, so we tend to put everything into code.
>
> In a way, method properties are a reification of comments, meant to be utilized by the system. It allows the system to know more about this piece of code than "this is a sequence of message sends". This meta information could as well be represented elsewhere, but putting it in as text along with the code lets us re-use the interface (text editing).
>
> - Bert -
>

> Textual representation is limitating (a good example is a programmed
> icon versus an artistic one), but easier to manage and reproduce.
>
> When I worked with VW, I used objects a lot at the beginning, but when
> bored porting from an image to the other (the problem being how to be
> sure I did not forget an object), I cut my wings and fell back to
> text.
>
> Nicolas
>
>

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