2010/4/26 Hannes Hirzel hannes.hirzel@gmail.com:

Thank you for the explanations. In particular reading the comment in the Pragma class was helpful. I feel now much more comfortable with the idea of using them. However I still think they are more related to VM primitives and configuration issues. The menu is a GUI related thing and having a MenuSpec feels somewhat more natural....

--Hannes

P.S. There are currently 854 methods which have a pragma in them.

That's why we should name them (Method) Annotation rather than Pragma...

Nicolas

On 4/26/10, Levente Uzonyi leves@elte.hu wrote:

...

On Mon, 26 Apr 2010, Hannes Hirzel wrote:

...

Hello Philipp

I took a fresh 4.1 image, updated it to 10012, and loaded Morphic-phite.429.mcz.

As the comments were fine I was quickly able to write an example (code below).

Then I had to choose 'Rebuild menus'

It worked fine. The question is now (see another thread by Bert) if we should go or your solution (MenuSpec based) or the one by Steve Wessels (Pragma based).

It's Balázs Kósi who implemented the registration method with pragmas (http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149534.htm... ).

...

I do not feel too comfortable with pragmas yet whereas the MenuSpec is something I easily understand. And in addition I have the gut feeling that pragmas are meant for some more basic things (a kind of compiler directive, see http://en.wikipedia.org/wiki/Directive_%28programming%29)

Pragmas in Squeak are not directives (though they can be used as directives) but a way to add metadata to a method. So the wikipedia page is irrelevant. If take a look at the class comment of Pragma, you'll feel more comfortable with them. (I think that we should convert all preferences to pragma-style. It could be a goal for 4.2.)

...

Like Bert  I would like to see some discussion **on this issue, but not too along as I would like to start using this feature asap.

We should review both methods, consider the benefits and drawbacks and then make a decision.

Levente

...

Hannes

** The thread started by Bert at http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149563.htm...

---

Model subclass: #MyReallyNiceApplication      instanceVariableNames: ''      classVariableNames: ''      poolDictionaries: ''      category: 'MyMenuTests'!

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

MyReallyNiceApplication class      instanceVariableNames: ''!

!MyReallyNiceApplication class methodsFor: 'as yet unclassified' stamp: 'hjh 4/26/2010 08:52'! menuEntrySpecification      "Test to add another entyr in the Help menu"

^MenuEntrySpec newForDockingBarFrom: (Dictionary newFromPairs: #(              #contents 'Hello?'              #location #('Help' 'a subMenu' 'another subMenu')              #target MenuMorph #selector #inform: #arguments #('Hello World!!')              )) ! !

On 4/26/2010 11:48 AM, Eliot Miranda wrote:

OK, so Pragma is bad; its historical from "primitive pragma". But Annotation doesn't capture the potentially executable flavour of pragmas. How about MethodMetaMessage? (mmm, yum :) ) We could talk about meta-messages for short. "Add a meta-message that does ..." etc...

But "primitive pragma" is every bit as wrong. A pragma is something that gives the compiler information about the code without being code itself. Primitives are't pragmas, primitives are *code* (if you don't believe me, just remove all of them and see how that goes).

By definition, a "pragma" is an interface between the code and the compiler, something where the code conveys meta-information to the compiler. For example, this is a pragma (assuming the compiler understands it):

foo <inline: true>

bar <tailcut: true>

The first one might instruct the compiler to generate the code for this method inline, the second one to eliminate tail recursion.

None of these, however, are pragmas:

foo "Not a pragma since it's not for the compiler" <preference: 'Foo Preference' ... >

apiGetWindowFocus "Not a pragma since it's code" <apicall: ulong 'GetWindowFocus' (void)>

etc. I should also add that before the introduction of the so-called "pragmas" there was only *code* used in the <> syntax (primitives and FFI calls) and the change to allow non-code entities is something that, although useful, still worries me because of the conceptual issues associated with mixing code and non-code entities. We wouldn't even have that discussion if <> just meant "code".

Cheers, - Andreas

On 4/26/2010 1:14 PM, Igor Stasenko wrote:

On 26 April 2010 22:05, Andreas Raabandreas.raab@gmx.de wrote:

...

On 4/26/2010 11:48 AM, Eliot Miranda wrote:

...

OK, so Pragma is bad; its historical from "primitive pragma". But Annotation doesn't capture the potentially executable flavour of pragmas. How about MethodMetaMessage? (mmm, yum :) ) We could talk about meta-messages for short. "Add a meta-message that does ..." etc...

But "primitive pragma" is every bit as wrong. A pragma is something that gives the compiler information about the code without being code itself. Primitives are't pragmas, primitives are *code* (if you don't believe me, just remove all of them and see how that goes).

By definition, a "pragma" is an interface between the code and the compiler, something where the code conveys meta-information to the compiler. For example, this is a pragma (assuming the compiler understands it):

foo <inline: true>

bar <tailcut: true>

The first one might instruct the compiler to generate the code for this method inline, the second one to eliminate tail recursion.

None of these, however, are pragmas:

foo "Not a pragma since it's not for the compiler" <preference: 'Foo Preference' ... >

apiGetWindowFocus "Not a pragma since it's code" <apicall: ulong 'GetWindowFocus' (void)>

etc. I should also add that before the introduction of the so-called "pragmas" there was only *code* used in the<> syntax (primitives and FFI calls) and the change to allow non-code entities is something that, although useful, still worries me because of the conceptual issues associated with mixing code and non-code entities. We wouldn't even have that discussion if <> just meant "code".

Pragmas are not code, even in old and limited forms, they simply contain a meta-information for compiler.

That is *precisely* what I said in the beginning: "A pragma is something that gives the compiler information about the code without being code itself". Here, I was referring to "<> syntax" which used to be code, and now it no longer is. Calling it "pragma" however is just completely and utterly wrong in whichever way you look at it.

If pragmas would be the code, then i expect them to look like code i.e.:

I never claimed that that "pragmas are code". In fact, I said *specifically* the opposite.

Cheers, - Andreas

On 26 April 2010 23:41, Andreas Raab andreas.raab@gmx.de wrote:

On 4/26/2010 1:14 PM, Igor Stasenko wrote:

...

On 26 April 2010 22:05, Andreas Raabandreas.raab@gmx.de  wrote:

...

On 4/26/2010 11:48 AM, Eliot Miranda wrote:

...

OK, so Pragma is bad; its historical from "primitive pragma".  But Annotation doesn't capture the potentially executable flavour of pragmas.  How about MethodMetaMessage?  (mmm, yum :) )  We could talk about meta-messages for short. "Add a meta-message that does ..." etc...

But "primitive pragma" is every bit as wrong. A pragma is something that gives the compiler information about the code without being code itself. Primitives are't pragmas, primitives are *code* (if you don't believe me, just remove all of them and see how that goes).

By definition, a "pragma" is an interface between the code and the compiler, something where the code conveys meta-information to the compiler. For example, this is a pragma (assuming the compiler understands it):

foo        <inline: true>

bar        <tailcut: true>

The first one might instruct the compiler to generate the code for this method inline, the second one to eliminate tail recursion.

None of these, however, are pragmas:

foo        "Not a pragma since it's not for the compiler"        <preference: 'Foo Preference'          ...        >

apiGetWindowFocus        "Not a pragma since it's code"        <apicall: ulong 'GetWindowFocus' (void)>

etc. I should also add that before the introduction of the so-called "pragmas" there was only *code* used in the<>  syntax (primitives and FFI calls) and the change to allow non-code entities is something that, although useful, still worries me because of the conceptual issues associated with mixing code and non-code entities. We wouldn't even have that discussion if <>  just meant "code".

Pragmas are not code, even in old and limited forms, they simply contain a meta-information for compiler.

That is *precisely* what I said in the beginning: "A pragma is something that gives the compiler information about the code without being code itself". Here, I was referring to "<> syntax" which used to be code, and now it no longer is. Calling it "pragma" however is just completely and utterly wrong in whichever way you look at it.

...

If pragmas would be the code, then i expect them to look like code i.e.:

I never claimed that that "pragmas are code". In fact, I said *specifically* the opposite.

Ok, then i wonder, what is the subject of discussion? If its only about terminology, then its not interesting. We may call it pragma, method annotation or whatever. I think that more improtant is how we handling it and what we can do with it.

Cheers,  - Andreas

On 26.04.2010, at 23:13, Hannes Hirzel wrote:

On 4/26/10, Igor Stasenko siguctua@gmail.com wrote:

...

Ok, then i wonder, what is the subject of discussion? If its only about terminology, then its not interesting. We may call it pragma, method annotation or whatever. I think that more improtant is how we handling it and what we can do with it.

The subject of the discussion is that we need a clear concept what pragmas are and what they are not. Concepts have names. The names invoke the concepts in people's minds. And the names have connotations. It is about communication to get understood.

OK, this discussion diverts. The point of departure is that we need to decide if we want the MenuRegistry to be pragma based or MenuSpec based.

This leads me to think that for the MenuRegistry I prefer MenuSpecs (which I actually did before).

So let's move ahead please and have somebody of the commiters put the MenuRegistry in the trunk. Philipp Tessenow has posted his third version** of the MenuRegistry today to the inbox. May I ask one of the commiters to have a look at it please and if there are no strong objections commit it to the trunk?

** http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149641.htm...

--Hannes

This discussion is quite separate from the menu definitions, so please do not mix the two.

In the other thread I felt the general opinion was leaning towards the annotation-based variant of Balázs.

- Bert -

On 27 April 2010 00:23, Andreas Raab andreas.raab@gmx.de wrote:

On 4/26/2010 1:56 PM, Igor Stasenko wrote:

...

...

...

If pragmas would be the code, then i expect them to look like code i.e.:

I never claimed that that "pragmas are code". In fact, I said *specifically* the opposite.

Ok, then i wonder, what is the subject of discussion?

The subject of the post was an attempt to clarify what pragmas are and what they aren't. Given that even Eliot is confused about it by referring to "primitive pragmas" that seemed worthwhile all by itself.

...

If its only about terminology, then its not interesting. We may call it pragma, method annotation or whatever. I think that more improtant is how we handling it and what we can do with it.

Terminology is important and the terminology we currently have is *extremely* confusing. People refer to "pragmas" and whenever a third party hears that they think "oh, compiler stuff, better stay away from it" not realizing that that's not what these are. This is how this discussion started after all.

Ok. Observing a Squeak's history i seen an attempts to allow methods to use an arbitrary objects as literals. Or, by analogy, a method's properties can carry any objects you may need. I thinks this is a most generic form of what current 'pragmas' could evolve to. So, from this point of view, pragmas is a subset of 'additional arbitrary method state', which having a formally defined structure 'instance of Pragma class'.

Cheers,  - Andreas

I do not really understand this joke in particular as Andreas writes

<citation>Terminology is important and the terminology we currently have is *extremely* confusing. People refer to "pragmas" and whenever a third party hears that they think "oh, compiler stuff, better stay away from it" not realizing that that's not what these are. This is how this discussion started after all.</citation>

I agree with him. Please note the workd 'extremly'. And that is why I am reluctant having these pragmas 'crawl' into menu definitions.

As I have seen so far - Pragmas are used in connection with primitives - they are used in connection with package versions.

Therefore I do not see a need to connect them to menus.

Bert, if you insist on having them for the menus then we need to add comments explaining that once more the Smalltalk community has gone for another idiosyncratic term.

--Hannes

On 4/26/10, Lawson English lenglish5@cox.net wrote:

Andreas Raab wrote:

...

On 4/26/2010 1:56 PM, Igor Stasenko wrote:

...

...

...

If pragmas would be the code, then i expect them to look like code i.e.:

I never claimed that that "pragmas are code". In fact, I said *specifically* the opposite.

Ok, then i wonder, what is the subject of discussion?

The subject of the post was an attempt to clarify what pragmas are and what they aren't. Given that even Eliot is confused about it by referring to "primitive pragmas" that seemed worthwhile all by itself.

...

If its only about terminology, then its not interesting. We may call it pragma, method annotation or whatever. I think that more improtant is how we handling it and what we can do with it.

Terminology is important and the terminology we currently have is *extremely* confusing. People refer to "pragmas" and whenever a third party hears that they think "oh, compiler stuff, better stay away from it" not realizing that that's not what these are. This is how this discussion started after all.

Could take a page from QM and just refer to "<>" as Bra-Ket notation...

:-)

Lawson

Bert,

To be precise, _you_ say it is silly. _I_ say it's not. You call them "guys" because it seems that you do dare anymore to use their name....

Yes, I do not question the usefulness of pragmas for what they have been used so far. Primitives and version control related things. I oppose to use them in addition for menu definitions.

In your conversation so far you used the term 'method-annotations' as a synonym for pragma. This is interesting and might lead to a solution for this discussion.

It's about 'conceptualisation'. Overloading a concept with too many meanings was never a good idea in system design.

And: to me the code for the menu definitions looks ugly. A kind of assembler like, lisp-s expression thing with a lot of implied assumptions.

The MenuSpec is a straighforward thing. And I think it is more appealing for the younger generation.

I think I have said now enough about this issue and will not comment on this anymore.

The practical problem we are currently facing with Squeak 4.1 is that it cannot display pictures in the the file browser and that adding entries to the menu is not possible in a clean way.

--Hannes

On 4/26/10, Bert Freudenberg bert@freudenbergs.de wrote:

On 27.04.2010, at 00:21, Hannes Hirzel wrote:

...

...

Terminology is important and the terminology we currently have is *extremely* confusing.

And that is why I am reluctant having these pragmas 'crawl' into menu definitions.

Now that's just silly, sorry. Nobody is questioning the utility of these guys, whatever we call them.

• Bert -

On 4/26/10, Andreas Raab andreas.raab@gmx.de wrote:

On 4/26/2010 3:47 PM, Hannes Hirzel wrote:

...

And: to me the code for the menu definitions looks ugly. A kind of assembler like, lisp-s expression thing with a lot of implied assumptions.

I think you're missing the point of why one would use an annotation. They're there for discovery by other code. You are basically announcing "hey if anyone cares, here's an action that you might want to place in a menu".

MenuSpec doesn't achieve that. Yes, you got a menu spec, but now what? You also need a registry, let's say TheWorldMenu. Then you add another registry for TheMainDockingBar. Then we refactor this and introduce new classes, say the TheMainMenu and TheContextMenu. Now you've got to deal with four different situations. This all goes away by using annotations. If there's code that knows how to discover these specs, it will do so. If not, it just leaves the code alone.

Most importantly a third party trying to extend the main menu doesn't need to update their code because the implementation in the base system changes.

...

The MenuSpec is a straighforward thing. And I think it is more appealing for the younger generation.

I fail to see what age has to do with this discussion. However, if you look at the "current" crowd of programming languages they pretty much all have annotations, from C# to Python, which are used for very similar purposes.

...

The practical problem we are currently facing with Squeak 4.1 is that it cannot display pictures in the the file browser and that adding entries to the menu is not possible in a clean way.

Correct, but I see this as a an example of a discussion on how we achieve a more decoupled system. For the purpose at hand, where we'd like 3rd parties to use and extend the base system while allowing the base system itself to evolve, I find the annotation-based discovery superior to hardcoded references to classes and registries that may not exist in this form in the future.

Cheers,

• Andreas

Thank you Andreas for this valuable in-depth explanation. It is convincing for me.

--Hannes

Explain please. I must be too sleepy to follow this.

- Steve

On Apr 26, 2010, at 6:45 PM, Igor Stasenko siguctua@gmail.com wrote:

On 27 April 2010 02:11, Andreas Raab andreas.raab@gmx.de wrote:

...

I find the annotation-based discovery superior to hardcoded references to classes and registries that may not exist in this form in the future.

+1

...

Cheers,

• Andreas

-- Best regards, Igor Stasenko AKA sig.

On 27 April 2010 02:45, Igor Stasenko siguctua@gmail.com wrote:

On 27 April 2010 02:11, Andreas Raab andreas.raab@gmx.de wrote:

...

I find the annotation-based discovery superior to hardcoded references to classes and registries that may not exist in this form in the future.

+1

However, i'd like to add, that indirect forms of declarations (like pragma annotations) is not always sufficient, because it makes impossible a direct communication between services, and thus having a limited potential.

The code example like following:

MenuEntrySpec newFrom: (Dictionary newFromPairs: #( contents 'Well... hello?' help 'Displays the Hello World' location ('Help') target MenuMorph selector inform: arguments ('Hello World!') position first))

introducing a rigid factors, because of use of globals (here - MenuEntrySpec and MenuMorph).

In contrast, if we turn it into a set of declarations like this

<createDockingBarMenuWithPriority: 50> <fillDockingBarMenu: #extras priority: 20>

is just an annotations, which not quite informal, since there is no usual sender-implementor chain and no direct communication, which can be tracked, debugged. You should implement a separate discovery mechanism, which searching for these annotations and controls the menu creation & its properties. Also, there is no any guarantee, that these annotations will be taken into account by system, while obviously a package author expects from a system to react on them and act accordingly.

So, we could have our cake and eating it too: - do not use globals (like MenuEntrySpec). Really, a format (or class) which is used for holding a menu spec is totally irrelevant to an external package. So, why external package should care about these details, why not like following:

Object>>globalMenuRegistry ^ World menuRegistry "whatever"

MyExternalPackageClass class>>initialize self addMenuEntry.

MyExternalPackageClass class>>addMenuEntry

self globalMenuRegistry addMenuEntry: #( contents 'Well... hello?' help 'Displays the Hello World' location ('Help') target selector #inform: arguments ('Hello World!') position first) forClass: self

So, as simple as that: - an external package expects from system to support a certain protocol, which can be used to access various system services (in our case , this is a #globalMenuRegistry) - an external package expects from menuRegistry to support a certain protocol, which can be used to add menu entries and control other various properties.

So, that's how we can at the same time keep system decoupled, and be able to have a direct communications between service & consumer. Just stop using globals and build the basic system infrastructure based on message sends and protocols.

...

Cheers,  - Andreas

-- Best regards, Igor Stasenko AKA sig.

On 27 April 2010 05:08, Andreas Raab andreas.raab@gmx.de wrote:

On 4/26/2010 5:13 PM, Igor Stasenko wrote:

...

So, we could have our cake and eating it too:

• do not use globals (like MenuEntrySpec). Really, a format (or class)

which is used for holding a menu spec is totally irrelevant to an external package. So, why external package should care about these details, why not like following:

Object>>globalMenuRegistry   ^ World menuRegistry "whatever"

MyExternalPackageClass class>>initialize   self addMenuEntry.

MyExternalPackageClass class>>addMenuEntry

self globalMenuRegistry addMenuEntry: #(        contents 'Well... hello?'                 help 'Displays the Hello World'                 location ('Help')                 target selector #inform: arguments ('Hello World!')                 position first)       forClass: self

So, as simple as that:  - an external package expects from system to support a certain protocol, which can be used to access various system services (in our case , this is a #globalMenuRegistry)

• an external package expects from menuRegistry to support a certain

protocol, which can be used to add menu entries and control other various properties.

So, that's how we can at the same time keep system decoupled, and be able to have a direct communications between service&  consumer. Just stop using globals and build the basic system infrastructure based on message sends and protocols.

That ends up with code like here:

MCWorkingCopy class>>initialize         (TheWorldMenu respondsTo: #registerOpenCommand:)         ifTrue: [TheWorldMenu registerOpenCommand: {'Monticello Browser'. {self. #open}}]

nope it doesn't. It should look like:

MCWorkingCopy class>>initialize self worldMenu registerOpenCommand: {'Monticello Browser'. {self. #open}}

which is precisely why I don't like it. It is also subject to the evolution system - how long is it going to take until we figure that the method shouldn't be called Object>>globalMenuRegistry etc.

But same applies to annotations.

How long it will take to figure out that instead of

<createDockingBarMenuWithPriority: 50>

you need:

<createDockingBarMenuWithPriority: 50 andColor: #red> ?

Take it or leave it, but all such #createDockingBarMenuWithPriority: is also defines a protocol, which something somewhere must recognize and react on it in order to make things work. Isnt?

And so, i think designing a good, future-proof protocols is answer to your question.

I'm not saying that we should hastily add tons of Object>>serviceXXxXxxxRegistry etc..

lets wisely consider what we need and slowly introduce it by deprecating the old uses.

Finally, I should also add that you *can* browse senders and implementors of annotations. Try for example browsing senders/implementors of #preference:category:description:type: to see what I mean.

Yes, you can. But still its a little different from putting a halt and see how it works and where it goes.

Cheers,  - Andreas

On 4/26/2010 8:04 PM, Igor Stasenko wrote:

On 27 April 2010 05:08, Andreas Raabandreas.raab@gmx.de wrote:

...

That ends up with code like here:

MCWorkingCopy class>>initialize (TheWorldMenu respondsTo: #registerOpenCommand:) ifTrue: [TheWorldMenu registerOpenCommand: {'Monticello Browser'. {self. #open}}]

nope it doesn't. It should look like:

MCWorkingCopy class>>initialize self worldMenu registerOpenCommand: {'Monticello Browser'. {self. #open}}

That assumes that #worldMenu is on class Object. An assurance that you can't make over time. So whoever is trying to extend the system is forced to adapt the code for any and all supported versions since you don't have a way of safely ignoring things.

...

which is precisely why I don't like it. It is also subject to the evolution system - how long is it going to take until we figure that the method shouldn't be called Object>>globalMenuRegistry etc.

But same applies to annotations.

How long it will take to figure out that instead of

<createDockingBarMenuWithPriority: 50>

you need:

<createDockingBarMenuWithPriority: 50 andColor: #red> ?

I don't know. But it doesn't break. Even in its most naive use. The service isn't recognized by the system you install it in, but it doesn't blow up in your face. Given that we're trying to move things forward and build them in a modular way, I think that's a good property.

BTW, only when you put *all* of it together, avoiding the need to refer to external global class names, avoiding the need to explicitly test for method compliance, automatic discovery by many tools (i.e., both the world menu and the docking bar can discover the same menu annotation but you'd have to provide separate selectors or globals to adjust for that), being both forward and backwards compatible; so when you put *all* of this together, there is no doubt in my mind that annotations are superior to the proposed alternatives. They have weaknesses, admitted, but these weaknesses are negligible for an application like we're discussing here.

And so, i think designing a good, future-proof protocols is answer to your question.

That's definitely an important aspect and holds for annotations as well.

I'm not saying that we should hastily add tons of Object>>serviceXXxXxxxRegistry etc..

lets wisely consider what we need and slowly introduce it by deprecating the old uses.

Are you actually proposing to introduce Object>>worldMenu? If so, I'm completely opposed to the proposal. Polluting the global namespace like that serves no purpose whatsoever.

OTOH, if you're saying that we should evaluate the use of annotations carefully in the context of each potential use, I'm with you. I don't like an abuse of annotations either. However, for situations like we're talking about, where third party code tries to add services to the base system, I think it's a good idea. That includes its use for preferences, the world menu / docking bar, and for example file services.

...

Finally, I should also add that you *can* browse senders and implementors of annotations. Try for example browsing senders/implementors of #preference:category:description:type: to see what I mean.

Yes, you can. But still its a little different from putting a halt and see how it works and where it goes.

True. It's harder to debug annotations if they don't do what you think they should. A good reason for keeping 'em simple.

Cheers, - Andreas

On 27.04.2010, at 00:47, Hannes Hirzel wrote:

And: to me the code for the menu definitions looks ugly. A kind of assembler like, lisp-s expression thing with a lot of implied assumptions.

You mean this?

MenuEntrySpec newFrom: (Dictionary newFromPairs: #( contents 'Well... hello?' help 'Displays the Hello World' location ('Help') target MenuMorph selector inform: arguments ('Hello World!') position first))

Yes, looks a lot like s-expressions. No, I don't like it either. Glad we agree on that. But weren't you arguing *for* this? I'm getting confused. Balázs proposed this:

<createDockingBarMenuWithPriority: 50>

<fillDockingBarMenu: #extras priority: 20>

- Bert -

On 4/26/10, Hannes Hirzel hannes.hirzel@gmail.com wrote:

On 4/26/10, Bert Freudenberg bert@freudenbergs.de wrote:

...

On 27.04.2010, at 00:47, Hannes Hirzel wrote:

...

And: to me the code for the menu definitions looks ugly. A kind of assembler like, lisp-s expression thing with a lot of implied assumptions.

You mean this?

MenuEntrySpec newFrom: (Dictionary newFromPairs: #( contents 'Well... hello?' help 'Displays the Hello World' location ('Help') target MenuMorph selector inform: arguments ('Hello World!') position first))

Yes, I agree with you Bert. It looks somewhat like s-expressions. But it need not. I could construct the dictionary with 'regular' Smalltalk code. Having a dictionary to move parameters around is quite common.

However as I said in my previous message - the pragma based solution is fine for me.

--Hannes

Nevermind.. I'm late to this party..

On Wed, Apr 28, 2010 at 2:18 PM, Chris Muller asqueaker@gmail.com wrote:

...

Yes, I do not question the usefulness of pragmas for what they have been used so far. Primitives and version control related things. I oppose to use them in addition for menu definitions.

Hi Hannes, I agree with you.  A new non-Smalltalk construct appears and we see that it starts to get used for lots of things where before we would have just used plain Smalltalk..

Can we stay with Smalltalk everywhere except where it's impossible or impractical to?

...

adding entries to the menu is not possible in a clean way.

I don't know about displaying the pictures, I just use the 'open' button.  But, I do use the "services" function to add my own custom application functions to the file-list.  Did you know about that or are you saying that it needs improvement..?

...

--Hannes

On 4/26/10, Bert Freudenberg bert@freudenbergs.de wrote:

...

On 27.04.2010, at 00:21, Hannes Hirzel wrote:

...

...

Terminology is important and the terminology we currently have is *extremely* confusing.

And that is why I am reluctant having these pragmas 'crawl' into menu definitions.

Now that's just silly, sorry. Nobody is questioning the utility of these guys, whatever we call them.

• Bert -

On 4/26/2010 3:29 PM, Bert Freudenberg wrote:

On 27.04.2010, at 00:21, Hannes Hirzel wrote:

...

...

Terminology is important and the terminology we currently have is *extremely* confusing.

And that is why I am reluctant having these pragmas 'crawl' into menu definitions.

Now that's just silly, sorry. Nobody is questioning the utility of these guys, whatever we call them.

Indeed. Nobody is questioning the utility. Personally, I still find "method property" to be the best name since it doesn't presume whether the property has an impact on code or not. A primitive can be a method property that represents code, a pragma can be a property that represents a compiler instruction, an annotation can be a property that is used for discovery.

Cheers, - Andreas

On Mon, Apr 26, 2010 at 12:05 PM, Andreas Raab andreas.raab@gmx.de wrote:

On 4/26/2010 11:48 AM, Eliot Miranda wrote:

...

OK, so Pragma is bad; its historical from "primitive pragma". But Annotation doesn't capture the potentially executable flavour of pragmas. How about MethodMetaMessage? (mmm, yum :) ) We could talk about meta-messages for short. "Add a meta-message that does ..." etc...

But "primitive pragma" is every bit as wrong. A pragma is something that gives the compiler information about the code without being code itself. Primitives are't pragmas, primitives are *code* (if you don't believe me, just remove all of them and see how that goes).

I know, but within ParcPlace a <primitive: 123> mark was /called/ a primitive pragma, and so "pragma" was the term we used (without sufficient thought) when we did the menu and exception "pragma" work in vw3.0.

By definition, a "pragma" is an interface between the code and the compiler, something where the code conveys meta-information to the compiler. For example, this is a pragma (assuming the compiler understands it):

foo <inline: true>

bar <tailcut: true>

The first one might instruct the compiler to generate the code for this method inline, the second one to eliminate tail recursion.

None of these, however, are pragmas:

foo "Not a pragma since it's not for the compiler" <preference: 'Foo Preference' ... >

apiGetWindowFocus "Not a pragma since it's code" <apicall: ulong 'GetWindowFocus' (void)>

etc. I should also add that before the introduction of the so-called "pragmas" there was only *code* used in the <> syntax (primitives and FFI calls) and the change to allow non-code entities is something that, although useful, still worries me because of the conceptual issues associated with mixing code and non-code entities. We wouldn't even have that discussion if <> just meant "code".

Cheers,

• Andreas

Travis, I like the name <method tag>. I have been checking out definitions for pragma today and the way it is used is in connection with compiler directives. The name as such refers to 'pragmatic information' which actually would have the wider meaning we want to use it for.

However the name <method tag> avoids problems. And people will feel at ease because of the < > bracket notation.

So topic is not dead at all. To the contrary: Andreas has been busy today with the Pharo community to work on <method tags> for preferences. That we get a compatible solution. (details see Pharo list).

Your points are well noted. Yes it is tempting to grow micro-DSLs with <method tags>.

The challenge is now to get a good solution.

--Hannes

P.S. From the link cited below

Menu Items Are Objects Too

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

The remark at the end should be put in BOLD <citation> There is a "trap" that we seem to fall in repeatedly with these method tags. We try to program with them. Every experience I have like this convinces me that this is a bad idea. We should program with Smalltalk. We should use tags simply to annotate simple meta data to a given method. </citation>

On 4/29/10, Travis Griggs travisgriggs@gmail.com wrote:

Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from VisualWorks land, where they originated.

1. We use them more and more. But judiciously. What they are really

good for is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.

Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.

2. I push, at ever juncture I can, the term <tagged methods> and

<method tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).

3. You can get carried away with <method tags>. It's tempting to grow

little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

4. History repeats itself, I think I wrote a post along these lines,

about 3+ years ago. I've slept since then tho, so I'm not sure.

-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval

2010/4/30 Steve Wessels steve@squeak.preeminent.org:

Good reminder, Travis.

Yes, thank you, your blog entry brings some water to Pharo mill (not sure whether this french idiom can be translated literally though).

Nicolas

...

There is a "trap" that we seem to fall in repeatedly with these method tags. We try to program with them. Every experience I have like this convinces me that this is a bad idea. We should program with Smalltalk.

On Apr 29, 2010, at 8:23 PM, Andreas Raab wrote:

On 4/29/2010 1:23 PM, Travis Griggs wrote:

...

Weighing in on a 2 day dead topic is probably passe` around here... :)

It's not quite dead yet :-)

...

2. I push, at ever juncture I can, the term <tagged methods> and

<method tags>. The <tag> term grew on me for a set of reasons.

I think that's a great term. It doesn't have the compiler connotations of "pragma", is shorter than "annotation" yet very concise and flexible. I like the sound of, e.g., "the apicall tag instructs the compiler to generate the code for some FFI call", "the preference tag allows discovery of preferences", the "type tag can be used to annotate variables". It really works for me.

In fact, I raise my hand and vote for renaming Pragma to MethodTag :-)

...

3. You can get carried away with <method tags>. It's tempting to grow

little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

I've discussed this particular issue with Eliot at length in order to understand what caused these issues. I agree with the conclusion that it's dangerous to use method tags as DSLs, and that if the level of fine-grained control one needs reaches the level you're describing in your post, tags are not the solution.

I think it's more fundamental than that. It's that if you're not careful, you end up with a tag that's trying to serve two masters. It's trying to be something that can be used to discover the method, and at the same time encode the construction of a seemingly simple object.

Or maybe another way to put it is this. No idea if I can make this make sense. A tag is about meta data. It is very cool that in and of itself, it is a Smalltalk message syntax. It's a message about the message. As long as it is strictly about the real method, then to me, that makes sense. It fits in the meta sense. But when what I really have, is two pieces of behavior, one which describes a UI element, and another which describes something associated with the behavior, then that type of construct belongs in Smalltalk, where it's methods all the way down, where we implement mixtures of messages all the time. What happened with the Menu stuff, and what it appears may happen with your preferences stuff, at least from my cursory reading, is that you end up using the <tag> as a way of coupling two co-equal pieces of data.

For example, the menu stuff evolved over time to look like:

arbitraryMethod < stuff:that:encodes:how:to:wrap:this:behavior:in:a:very:specific:UI:implementation

self doSomeLogic; maybeCheckSomething; decideWhetherWeShouldContinueToGoOn; goAndDoSomething

But why not the other way around?

arbitraryMethod <menuMethodAction: #selectorToSend receiverAspect: #messageToGetReceiver arguments: #(#literal 'arguments')>

^MenuItem labeleled: 'Blah'; group: 'Whatever'; hopefullyYouGetThePoint; yourself

I could just as easily write an AutomaticMenuAugmentationCementMixer that worked just as well this way. Instead of limitations about what kind of UI's I could wrap around the action, I would have traded it for limitations in what kind of action I could express for my menu item object. Or I could have split it another way.

However, that doesn't preclude their use for a small set of menu declarations that we'd like to support going forward. Read the full argument here:

I'm not sure what your threshold for "small" would have been. Before we added the last and final <menu method tag> to "rule them all", VisualWorks had reached no less than 13 variants of the tag, with no end in sight. We were needing more. I'm reasonably sure that it didn't start out with 13, it started out with just a "small set", a sort of quick and easy shorthand for "the common cases."

One problem with this sort of 4GL'ification that was layered on top of VisualWorks 1.0 in this and other areas, was that you create an interesting dilemma for the programmer. There's two different ways of defining a Menu action now. I can go the supposed easy way with a quick tag shorthand notation, or I can send real messages. When do I choose which approach? How do I know when to give up on the one, and switch to the other? How do I swap back and forth? IMO, the effort is usually better spent making your API simple and easy to discover and use messages all the way down.

http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-disco...

Read.

Twice now.

Good stuff.

Discovery good.

Piggybacking other stuff into the discovery packet, bad. :)

-- Travis Griggs Objologist "I did not have time to write you a short program, so I wrote you a long one instead."

On Fri, Apr 30, 2010 at 2:00 AM, Travis Griggs travisgriggs@gmail.comwrote:

One problem with this sort of 4GL'ification that was layered on top of VisualWorks 1.0 in this and other areas, was that you create an interesting dilemma for the programmer. There's two different ways of defining a Menu action now. I can go the supposed easy way with a quick tag shorthand notation, or I can send real messages. When do I choose which approach? How do I know when to give up on the one, and switch to the other? How do I swap back and forth? IMO, the effort is usually better spent making your API simple and easy to discover and use messages all the way down.

This is a great summary of a common design issue. It happens when people make configuration files. HTML tags. Even when you make a Builder object in Smalltalk. It is hard to make sure there is only one way to do something, and when there are two ways, people have to choose, causing more work and making programming take longer.

-Ralph

On 4/30/10, Bert Freudenberg bert@freudenbergs.de wrote:

On 30.04.2010, at 05:23, Andreas Raab wrote:

...

On 4/29/2010 1:23 PM, Travis Griggs wrote:

...

2. I push, at ever juncture I can, the term <tagged methods> and <method

tags>. The <tag> term grew on me for a set of reasons.

I think that's a great term. It doesn't have the compiler connotations of "pragma", is shorter than "annotation" yet very concise and flexible. I like the sound of, e.g., "the apicall tag instructs the compiler to generate the code for some FFI call", "the preference tag allows discovery of preferences", the "type tag can be used to annotate variables". It really works for me.

In fact, I raise my hand and vote for renaming Pragma to MethodTag :-)

+1

Thanks Travis!

• Bert -

+1

--Hannes

Hi Travis,

Why do people need or want a different syntax for just another new object? I imagine one day where Smalltalk programmers are forced to write methods like:

...

selector

<menu ...> <primitive...> <documentation ... > <test ...> <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

In this tag-oriented world, I don't like to write tags, if that were the case I would switch to Java and all those XML they love so much. Note that changing language it's not just changing syntax, it's a new form of connectionism thinking which entails loss of knowledge, even in nonnatural languages.

Hernán

2010/4/29 Travis Griggs travisgriggs@gmail.com:

Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from VisualWorks land, where they originated.

1. We use them more and more. But judiciously. What they are really good for

is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.

Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.

2. I push, at ever juncture I can, the term <tagged methods> and <method

tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).

3. You can get carried away with <method tags>. It's tempting to grow little

micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

4. History repeats itself, I think I wrote a post along these lines, about

3+ years ago. I've slept since then tho, so I'm not sure.

-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval

The mechanism to discover preferences in method tags <pragma> is in the class

Preferences , class side , category 'dynamic preferences' , method

preference: prefName category: aCategory description: helpString type: typeSymbol

Then look for senders of this method. This gives you the methods with this tag in it. (38 so far, i.e. the process has just started)

--Hannes

On 4/30/10, Hannes Hirzel hannes.hirzel@gmail.com wrote:

The <...> syntax is already there. In fact since 3.9.

Go to class Pragma in 4.1, bring up the class comment. At the bottom you find the following

To browse ALL methods with pragmas in the system evaluate SystemNavigation default browseAllSelect: [:m| m pragmas notEmpty]

and to browse all nonprimitive methods with pragmas evaluate SystemNavigation default browseAllSelect: [:m| m primitive isZero and: [m pragmas notEmpty]]

These are actually not so many.

You mention an example

<menu ...> <primitive...> <documentation ... > <test ...> <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

Yes this is the direction things seem to head .....

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

...

Hi Travis,

Why do people need or want a different syntax for just another new object? I imagine one day where Smalltalk programmers are forced to write methods like:

...

...

selector

<menu ...> <primitive...> <documentation ... > <test ...> <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

In this tag-oriented world, I don't like to write tags, if that were the case I would switch to Java and all those XML they love so much. Note that changing language it's not just changing syntax, it's a new form of connectionism thinking which entails loss of knowledge, even in nonnatural languages.

Hernán

2010/4/29 Travis Griggs travisgriggs@gmail.com:

...

Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from VisualWorks land, where they originated.

1. We use them more and more. But judiciously. What they are really good

for is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.

Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.

2. I push, at ever juncture I can, the term <tagged methods> and <method

tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).

3. You can get carried away with <method tags>. It's tempting to grow

little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

4. History repeats itself, I think I wrote a post along these lines,

about 3+ years ago. I've slept since then tho, so I'm not sure.

-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval

What I have understood so far is that these method tags help to decouple things. Instead of my package having to do something (e.g. registering a preference) the base system "discovers" the preference settings of my package.

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

Hi Hannes,

I'm not talking about an instrumentation problem, I'm not having problems with finding things, the comment was intended to note that there whatever you may write with < .. > you may write it with real Smalltalk messages.

It's just a matter of finding the objects, and sometimes, adapting the tools.

Hernán

2010/4/30 Hannes Hirzel hannes.hirzel@gmail.com:

...

The <...> syntax is already there. In fact since 3.9.

Go to class Pragma in 4.1, bring up the class comment. At the bottom you find the following

To browse ALL methods with pragmas in the system evaluate        SystemNavigation default browseAllSelect: [:m| m pragmas notEmpty]

and to browse all nonprimitive methods with pragmas evaluate        SystemNavigation default browseAllSelect: [:m| m primitive isZero and: [m pragmas notEmpty]]

These are actually not so many.

You mention an example

<menu ...>  <primitive...>  <documentation ... >  <test ...>  <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

Yes this is the direction things seem to head .....

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

...

Hi Travis,

Why do people need or want a different syntax for just another new object? I imagine one day where Smalltalk programmers are forced to write methods like:

...

...

selector

<menu ...>    <primitive...>    <documentation ... >    <test ...>    <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

In this tag-oriented world, I don't like to write tags, if that were the case I would switch to Java and all those XML they love so much. Note that changing language it's not just changing syntax, it's a new form of connectionism thinking which entails loss of knowledge, even in nonnatural languages.

Hernán

2010/4/29 Travis Griggs travisgriggs@gmail.com:

...

Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from VisualWorks land, where they originated.

1. We use them more and more. But judiciously. What they are really good

for is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.

Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.

2. I push, at ever juncture I can, the term <tagged methods> and <method

tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).

3. You can get carried away with <method tags>. It's tempting to grow

little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

4. History repeats itself, I think I wrote a post along these lines,

about 3+ years ago. I've slept since then tho, so I'm not sure.

-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval

Actually this <cool thing> has been around for a long time in VisualWorks and Travis refers to the experience with that in this thread. May I ask you to go to the blog entry he refers to.

In fact if we go for this as well it should avoid these pitfalls....

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

Ok, and still not convinced at all the advantages of that approach over normal message sending. What's the real limitation of common objects for implementing a "discovering mechanism"? It's simply another subsystem, it could be easier or harder than others, but I'm sure you don't *need* to use already weird syntax to implement it. All the tags stuff smells like people wanting to experiment "cool things" with DSL's but is using us as testers.

Hernán

2010/4/30 Hannes Hirzel hannes.hirzel@gmail.com:

...

What I have understood so far is that these method tags help to decouple things. Instead of my package having to do something (e.g. registering a preference) the base system "discovers" the preference settings of my package.

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

...

Hi Hannes,

I'm not talking about an instrumentation problem, I'm not having problems with finding things, the comment was intended to note that there whatever you may write with < .. > you may write it with real Smalltalk messages.

It's just a matter of finding the objects, and sometimes, adapting the tools.

Hernán

2010/4/30 Hannes Hirzel hannes.hirzel@gmail.com:

...

The <...> syntax is already there. In fact since 3.9.

Go to class Pragma in 4.1, bring up the class comment. At the bottom you find the following

To browse ALL methods with pragmas in the system evaluate        SystemNavigation default browseAllSelect: [:m| m pragmas notEmpty]

and to browse all nonprimitive methods with pragmas evaluate        SystemNavigation default browseAllSelect: [:m| m primitive isZero and: [m pragmas notEmpty]]

These are actually not so many.

You mention an example

<menu ...>  <primitive...>  <documentation ... >  <test ...>  <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

Yes this is the direction things seem to head .....

--Hannes

On 4/30/10, Hernán Morales Durand hernan.morales@gmail.com wrote:

...

Hi Travis,

Why do people need or want a different syntax for just another new object? I imagine one day where Smalltalk programmers are forced to write methods like:

...

>selector

<menu ...>    <primitive...>    <documentation ... >    <test ...>    <.. put any meta "annotation" you like here ...>

...and finally Smalltalk code .....

In this tag-oriented world, I don't like to write tags, if that were the case I would switch to Java and all those XML they love so much. Note that changing language it's not just changing syntax, it's a new form of connectionism thinking which entails loss of knowledge, even in nonnatural languages.

Hernán

2010/4/29 Travis Griggs travisgriggs@gmail.com:

...

Weighing in on a 2 day dead topic is probably passe` around here... :)

I can weigh in with some practical/historical experience from VisualWorks land, where they originated.

1. We use them more and more. But judiciously. What they are really

good for is defining programatic categorization of methods, so that one can discover programatically subsets of behavior that a given Behavior implements. Examples include the obvious <settings..> and <menu..> sort of things. We use them in the RefactoringBrowser to make certain aspect easily pluggable, such as adding your own tool pane, navigator pane, or status pane. The inspector uses them to support arbitrary inspector fields on any object. We even use them in <test>s, because I've found that you tend to make better test selector names, when your brain isn't trying to negotiate coming up with a good selector name that describes what your test does AND begins with the 4 characters 'test'. I used them in production code more and more when I was at Key writing UIs and control systems for optical food sorting equipment.

Why not just use a method categories (protocols)? Because you can't quite put enough information there to make them useful, and they're stuck with just one category. You want simplicity and judicious application, deferring to good ol' messages as much as possible, but simple categories just don't provide enough.

2. I push, at ever juncture I can, the term <tagged methods> and

<method tags>. The <tag> term grew on me for a set of reasons. Technically, they result in "AnnotatedMethods", and one can call each item an "Annotation". But that's a big long word, and using small short words always keeps things simpler. I also liked the harmony with the fact that we live in a world dominated by <tag><markup><languages> and they're called tags there. Since we were using roughly the same syntax, why not go with it? It's also easier to draw an icon that shows up next to methods for <tagged methods> than it is for <annotated methods> (see attached pic).

3. You can get carried away with <method tags>. It's tempting to grow

little micro-DSLs with these things. They don't scale well for that. They're far from turing complete, and you're limited to literal objects. Best example of this is the nightmare that the method tags for menus were turning into VW. I wrote about this here:

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

4. History repeats itself, I think I wrote a post along these lines,

about 3+ years ago. I've slept since then tho, so I'm not sure.

-- Travis Griggs Objologist "The best way to know you have a mind is to change it" -Judge Pierre Leval

Hi Travis,

Thanks for your answer, some somments between lines

2010/5/1 Travis Griggs travisgriggs@gmail.com:

On Apr 30, 2010, at 11:32 AM, Hernán Morales Durand wrote:

...

Ok, and still not convinced at all the advantages of that approach over normal message sending. What's the real limitation of common objects for implementing a "discovering mechanism"? It's simply another subsystem, it could be easier or harder than others, but I'm sure you don't *need* to use already weird syntax to implement it. All the tags stuff smells like people wanting to experiment "cool things" with DSL's but is using us as testers.

I didn't implement them originally, I just live with them (happily enough) and make use of them. I'm curious what you would do differently? How would you make it so can send a message to Behavior X, and fetch me all of the methods that belong to a given service? Would you just use method categories? Or maybe just embed literal arrays in the CompiledMethod frame, and scan for those? Or pattern match something from method comments?

To me is not important who implement them but it is valuable to talk, learn and think about the consequences of adopting ideas not only at the convenience level, but at the whole picture level, these language issues affect how systems are thought, our perception of how things work, affect system's identity and in the end, to us as a social phenomenon.

Let's take an example with some rhetorical questions, if this line of adoption continues and some ST authority one day embeed in Smalltalk one of the many XML query languages, then still would be Smalltalk or it would be a reflectaphore of Smalltalk? And if later he embeed the most fashioned languages today, then it would became a mutant (or "variant" of what was once long time ago) ? I'm not doubting of the usefullness of a solution now for today's world problems, but it is simply too much solution developer narrative (read: tired of reading a particular kind of discourse), like if the community were stuck into a social dynamics open source book and arguments (thinking) were losing value in favor of... packages.

That's one of my problems with some (XXX) embedded solutions too. Again, XXX should be supercool for solving some problems, but why do not question its ideas beyond the majority rule and meritocracy *before* adopting it? We may ask: How many real systems were implemented using XXX ? What parts were changed and how? How many time took to the developers to learn and get used to program with XXX ? To what discourse belongs the solution what propose and proponents? There is a (hidden) scientific discourse? then take a note of the main units of work of scientific production: Research. There is a cultural or business discourse? etc.

Sorry for not offering you a clear alternative solution, there should be many creative ways to do it. I've seen a system with literal arrays embedded in the CompiledMethod frame for solving i18n at the tools level, i.e., without affecting the syntax or traditional developer tools but providing specialized browsers for automatic translation.

One person once told me that they were fine with the idea of annotating methods with metadata, but they didn't feel it belonged in the method syntax, that it should be a separate pane or something, is that your take as well?

If so, I can only offer some thoughts as to why it ended up the way it did.

I guess it was partly because there was already precedent for seeing something there with the <primitive: xxx> construct. It was known most developers weren't complaining about that, so use it a little more. Language developers aren't necessarily tool developers either, so when presented with the option of

a) writing new UI tools to have composite panes to edit the different aspects of methods

or

b) hack the compiler/scanner to generalize the <primitive: construct>

the second was probably a much more palatable approach.

Ironically (to me), there's already a precedent for this, before any <> discussion ever existed. There's already two pieces of related, but independent data squished together in the same chunk of text. The method signature at the top of a method is not really part of the method. You can copy/paste the body past the signature of a method into a workspace and inspect/doit. But if you include the Smalltalk looking signature from the top, it won't work, there's no lvalue and there's no statement terminator. In fact, the object that results from compiling the method syntax, it doesn't itself even know what it's selector is, but can only answer it for you, by going back to it's mclass and asking what signature it's got the method registered under. Taken to an extreme, we could argue these two texts don't belong in the same pane either.

Exactly, I was suprised the first time I've seen the links between MethodDictionary, CompiledMethod, sources, etc. And if you take a look at "low level" things like Multi-Methods, MethodWrappers, Instance-Based behavior, etc. I wonder why most developers (I know) still sees it in the form of hack tools and not as a natural way of working with a true reflective system. If you need hacks to implement new behaviors, then possibly the subsystem base design is not good enough.

Hernán

-- Travis Griggs Objologist Light travels faster than sound. This is why some people appear bright until you hear them speak...

I didn't understand Hernan's response. It complained about tags but didn't give any alternatives, and because I couldn't see any alternatives I had no idea what the complaints were about. But Colin's message is much more concrete and provides an easy to understand alternative.

If tags are a way of categorizing methods so that other tools can find them, an alternative is to find them based on their name. The SUnit testrunner will automatically run methods whose name starts with "test" if they are in subclasses of TestCase. When I studied OmniBrowser a year or two ago, I found the way commands were defined to be pretty easy. The main thing making them hard to learn was lack of up-to-date documentation (class comments would be nice!) but commands were one of the easier things to figure out.

Another alternative is to rind them based on the protocol they are in. SUnit tests are almost always in a protocol called "Testing". The TestRunner could have used that instead. The main problem with this is that Monticello uses protocols to specify packaging, though I think that was a bad design decision.

i don't see why method tags are so bad. They will become part of the standard reflective definition of methods. You'll be able to ask a class for all its methods with a particular tag, and you can easily get a collection of all methods in the system with a particular tag by iterating over the classes. To me, this is no different than asking a class for methods whose name starts with "test". Tags are better than depending on names, because when I look at a method with a funny name, I might think that the author did a bad job at naming it and "fix" the name. However, when I see a tag I will know that the author expects that method to be used for a particular purpose, and I will work on learning the purpose. So, I think that method tags communicate better than encoding information in names. To me, it doesn't seem any less object-oriented than encoding info in names. I've been programming in Smalltalk for 25 years, so I think my intuition should count for something.

-Ralph Johnson

On Sat, May 1, 2010 at 8:36 AM, Travis Griggs travisgriggs@gmail.comwrote:

On Apr 30, 2010, at 11:32 AM, Hernán Morales Durand wrote:

Ok, and still not convinced at all the advantages of that approach

...

over normal message sending. What's the real limitation of common objects for implementing a "discovering mechanism"? It's simply another subsystem, it could be easier or harder than others, but I'm sure you don't *need* to use already weird syntax to implement it. All the tags stuff smells like people wanting to experiment "cool things" with DSL's but is using us as testers.

I didn't implement them originally,

I came up with the idea and implemented it together with Steve Dahl for VisualWorks 30 where we first used them extensively for menu augmentation on package load. So if you want someone to blame, blame me :)

I just live with them (happily enough) and make use of them. I'm curious what you would do differently? How would you make it so can send a message to Behavior X, and fetch me all of the methods that belong to a given service? Would you just use method categories? Or maybe just embed literal arrays in the CompiledMethod frame, and scan for those? Or pattern match something from method comments?

One person once told me that they were fine with the idea of annotating methods with metadata, but they didn't feel it belonged in the method syntax, that it should be a separate pane or something, is that your take as well?

If so, I can only offer some thoughts as to why it ended up the way it did.

I guess it was partly because there was already precedent for seeing something there with the <primitive: xxx> construct.

That's right. But it also means that pragmas^H^H^H^H^H^H^Hmethod tags can be specified in a source file in. Whole talk of using UI mechanisms to separate method tags from methods might seem attractive it seems to me overcomplicated and unhelpful. A key idea with method tags is to associate them with specific methods (because the method tag is about the method in which it occurs) and since methods are specified textually a method tag's definition belongs in the text of the method. COmplicating browser UIs and vastly complicating the addition of method tags to methods brought in from source files seems to me to be a bad idea.

It was known most developers weren't complaining about that, so use it a

little more. Language developers aren't necessarily tool developers either, so when presented with the option of

a) writing new UI tools to have composite panes to edit the different aspects of methods

or

b) hack the compiler/scanner to generalize the <primitive: construct>

the second was probably a much more palatable approach.

I think that's unfair. It was much simpler and reliable to keep them in the method. It was expedient to use the <> escape syntax because it existed already and so we didn't have to extend the language or break old code adding method tags. Personally I think it worked out quite well.

Ironically (to me), there's already a precedent for this, before any <> discussion ever existed. There's already two pieces of related, but independent data squished together in the same chunk of text. The method signature at the top of a method is not really part of the method. You can copy/paste the body past the signature of a method into a workspace and inspect/doit. But if you include the Smalltalk looking signature from the top, it won't work, there's no lvalue and there's no statement terminator. In fact, the object that results from compiling the method syntax, it doesn't itself even know what it's selector is, but can only answer it for you, by going back to it's mclass and asking what signature it's got the method registered under. Taken to an extreme, we could argue these two texts don't belong in the same pane either.

Again saying the selector isn't part of the method strikes me as wrong. A method has a signature, which is the selector pattern (including arguments) at the start, and a body, just as e.g. a C function has a signature and a body. People have a head and a body. Just because a method is a compound doesn't make elements of the compound not parts of the compound. A class has methods. Without methods it isn't a lot of use.

There are contexts in which extracting the selector (and comment) and not displaying the method makes sense (API doc). But in general keeping the method's head in contact with it's body is a simple way of keeping the method alive and useful.

HTH Eliot

-- Travis Griggs Objologist Light travels faster than sound. This is why some people appear bright until you hear them speak...

On Tue, May 4, 2010 at 2:07 PM, Hannes Hirzel hannes.hirzel@gmail.comwrote:

On 5/3/10, Eliot Miranda eliot.miranda@gmail.com wrote:

...

On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <travisgriggs@gmail.com wrote:

...

I didn't implement them originally,

...

I came up with the idea and implemented it together with Steve Dahl for VisualWorks 30 where we first used them extensively for menu augmentation

on

...

package load. So if you want someone to blame, blame me :)

When was that? (VW3.0)

VW3.0 was released in 1998.

According to Lukas Renggli <method tags> were introduced in Squeak 3.9, probably end of 2006 (see http://ftp.squeak.org/3.9/ ), to go with the "modern world"...

However if you check out in the image they are not really used besides for the primitives.

I would like to see a menu implementation and Preferences using them. They might be useful for the HelpSystem (to tag methods of a certain importance as 'entry points' for code reading for example).

--Hannes