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).
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)
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.
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 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!!') )) ! !
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.
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!!') )) ! !
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 Mon, Apr 26, 2010 at 5:26 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
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...
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...
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 26 April 2010 22:05, 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).
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. If pragmas would be the code, then i expect them to look like code i.e.: <[ | x y | x := 5. y:= 6. x+y ] >
I treat a pragma as a message, sent to compiler/parser framework i.e. whenever compiler sees:
< foo: a with: z bar: zork>
its can be simply interpreted as a message sent to compiler(or parser): pragmaConsumer foo: a with: z bar: zork
where pragmaConsumer is an object which can do anything it wants for taking this information into account, when processing the method's source code.
Btw, it would be interesting to alter the compiler framework to support that cleanly. We can use a special class, PragmaProcessor , with all the messages like
PragmaProcessor >> primitive: aPrimitiveName module: aModuleName
and parser , in its #addPragma: could simply do:
addPragma: aPragma properties := self properties copyWith: aPragma "pragmaProcessor is a previously initialized PragmaProcessor instance" (pragmaProcessor respondsTo: aPragma keyword ) ifTrue: [ pragmaProcessor perform: aPragma keyword withArguments: aPragma arguments. ]
pragma processor then can call back the parser/compiler in case of need (like adding a primitive literal, setting a method's prim index etc), or do whatever extra it needs.
so, then we can keep a pragma processing code aside of parser/compiler and extend it easily to support various stuff we may need.
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.04.2010, at 22:41, Andreas Raab 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:
I think that "method annotation" captures the meaning best of the alternatives mentioned so far.
- Bert -
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 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
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 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.
Cheers, - Andreas
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
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
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
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 -
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/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
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
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
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 4/26/2010 4:55 PM, Steve Wessels wrote:
Explain please. I must be too sleepy to follow this.
Explain what? Did you read my post? What is unclear about it?
Cheers, - Andreas
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 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}}]
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.
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.
Cheers, - Andreas
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
In addition. What prevents us from defining a protocol to rule out other (unstable) protocols? :)
(self systemProtocol: 'Squeak4.1' ) ifNotNilDo: [:protocol | protocol globalMenuRegistry addStuff.... ]
On 27 April 2010 06:04, Igor Stasenko siguctua@gmail.com wrote:
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
-- Best regards, Igor Stasenko AKA sig.
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 April 2010 06:33, Andreas Raab andreas.raab@gmx.de wrote:
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.
Well, from other side, if it breaks, then you know that something goes wrong and needs to be fixed. Its really depends on intent. Nothing stopping you from implementing a DNU handler which ignoring uknown messages and warns user istead of opening debugger.
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.
I am not opposed to annotations. I'm just pointing out that they having own limits.
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.
Indeed.
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.
Not necessarily in Object. I'm already proposed before to use Smalltalk as a hub for all such things.. For example:
Smalltalk userInterface browser open.
Smalltalk userInterface mainMenu registerMenuItem: ....
Smalltalk vm version.
and so on.
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, 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))
Actually I would not call this s-expression. It is regular Smalltalk code because it uses keyword messages.
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 -
Basically I need to get used to the idea that we do menus in an orthogonal plane.
Are other programming languages doing this for menus as well? Java which I have been using in the last years surely not.
However as a whole - not too bad. I'm fine if you go ahead and commit the pragma based solution to the trunk.
--Hannes
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
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 -
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 -
Chris,
I was just thinking along the same lines. However the discussions led to a nice writeup by Andreas Raab
'Annotations for Service Discovery' http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-disco...
I think the arguments laid out there are convincing. The 'Menu Registry' thread has to be read in parallel.
That is the next area of application for pragmas (synomym 'method property' or 'method annotation') are the menu definitions.
It's like a second floor. Or a thing orthogonal to the regular source code in the methods. But pragmas are still Smalltalk messages. They are just sent used by different objects. The compiler / menu bar builder / documentation builder or whatever.
The question in the Menu registry thread is: 'How are method annotations for menus going to look like'.
--Hannes
P.S. I am currently checking out as what Pharo has done in this area.
On 4/28/10, Chris Muller asqueaker@gmail.com wrote:
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 2:23 PM, 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.
Let me be specific. I'm not confused (about this at least). I know that the old "primitive pragma" actually specified code. However, it was /called/ a primitive pragma, and the "pragma" terminology descends from that incorrect usage.
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.
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
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
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.
- 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.
- 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).
- 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...
- 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 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 :-)
- 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 :-)
- 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.
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:
http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-disco...
Cheers, - Andreas
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 :-)
- 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 :-)
- 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."
W00t! The word 'pragma' completely confused me. It made me think Perl pragma. Annotation to my ear (and this may just be me) implies more than what these things do. When I hear the word annotation, I think of something more like a class comment.
Tag is a perfect word for it. Please let's call them tags sooner than later! I hope it sticks.
On Fri, Apr 30, 2010 at 12:00 AM, Travis Griggs travisgriggs@gmail.comwrote:
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 :-)
- 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 :-)
- 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 30.04.2010, at 05:23, Andreas Raab wrote:
On 4/29/2010 1:23 PM, Travis Griggs wrote:
- 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 -
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:
- 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
The name method tag makes a lot of sense.
An example: If I have a method tagged with <systemsetting> I know how I can collect together all the settings in the whole image. No need for 'registering' ......
And the tag <primitive: ...> marks methods which have implementations in the virtual machine.
A tag like <menu> marks methods which should be called from the menu. Another <menu> tag tells the system which label to use and maybe another one which menu (something like this.... needs elaboration, this is an on-going discussion)
--Hannes
On 4/30/10, Hannes Hirzel hannes.hirzel@gmail.com wrote:
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:
- 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.
- 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.
- 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).
- 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...
- 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 <...> 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.
- 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.
- 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).
- 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...
- 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.
- 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.
- 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).
- 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...
- 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 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.
- 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.
- 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).
- 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...
- 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.
- 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.
- 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).
- 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...
- 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
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.
- 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.
- 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).
- 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...
- 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.
- 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.
- 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).
- 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...
- 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
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?
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.
-- Travis Griggs Objologist Light travels faster than sound. This is why some people appear bright until you hear them speak...
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...
On 2010-05-01, at 8:36 AM, Travis Griggs wrote:
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?
I wrestled with this issue when designing OmniBrowser, so perhaps exploring it with a concrete example might be illuminating.
The problem I had was this: I wanted OmniBrowser to be modular, so that you could load only parts of it. If you had a constrained environment, for example, you could load just a basic lightweight browser, but other folks could use the full RB functionality just by loading some additional packages. Or if you had some browser extensions that were only useful in certain situations you could publish it as a optional package that didn't require modifying the core browser code.
The solution I hit on was a system of commands. Commands are a sort of UI-independent abstraction used to build menus and button bars. A command provides a service (like, say, removing a method), and knows what sort of context is required for that service to make sense (eg, a method is selected). It also knows how to describe its self to the user ('remove method') without knowing what sort of UI (Morphic, MVC, Gtk) or widget (menu or button) is being used to present it.
When the browser needs to build a menu, it looks at the available commands, figures out which ones are applicable to the current state of the UI, and builds the appropriate menu. This makes it easy to extend the browser - just create a class that implements a simple protocol, and add a method that answers that class to the browser class you want to extend. It's more object-oriented than the ever-expanding pragma DSL that Travis was describing.
So far, so good, but there's still the problem of discovery! How do you gather up the list of commands that should be available for a given browser? I used reflection in OB: when the browser first opens, it searches its own dictionary for unary selectors that begin with 'cmd', and sends its self all those messages. It hangs on to the classes that get answered, and uses them to generate commands as needed. Nice and simple, but it's a bit of a hack.
Now that Pragmas (MethodTags) are well supported in Squeak and Pharo, I've been thinking of using them instead. At least it would be a "standard" hack, one that' used in other parts of the system. The question is how much to put in the tags? It could be as simple as <command>, and then scan for tagged methods instead of selectors with a prefix. Or it could be more complex, something that describes how to create commands.
Colin
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
Dear Ralph,
You're searching for a dialogue type which I'm not willing to accept. Not every dialogue is a problem-solving situation. It doesn't matter how to solve something if you're already absolutely convinced there is no problem in what you're using.
When you learn about historical linguistics and language transmition, acquisition and preservation you begin to understand some things which are difficult to link to "Computer Science" subjects, but they are very related. What we're dealing with is a grammaticalization because isn't like if the Smalltalk language doesn't let us build a good solution, is not like the verbal system is incomplete and the tags would represent a perfect universal innate grammar which we must take advantage no matter the cost, it is more like the plantation of a set of new conventions in the form of grammatical devices. Tags are not a radical language shift, but they are a begginning, like every innocent change in our lexicon. I'm wondering what will be our next "cool" notation and I don't know how so many developer's mental grammar shifted to tag-oriented speeching (but I suspect why :).
Do authoritative majority here want to start to promote new syntax for doing things? To how extent this will remain unnoticed? Linguists know that language users allows a certain degree of tolerable intelligibility before moving out to another language community. That happens between generations in natural languages, if language preservation is planned, then the transitional language users will will preserve its identity for most time. In computer languages that could happen rapidly.
The language in Smalltalk is a small language, that is, with a few number of speakers compared with "major" languages, but computer languages are also subjected to pressure from larger languages, and without economic and political influence, like dialects, they tend to dissapear (there is no death of a language, the users just move to another language but revivals almost never happen).
Cheers,
Hernán
2010/5/2 Ralph Johnson johnson@cs.uiuc.edu
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 5/3/10, Eliot Miranda eliot.miranda@gmail.com wrote:
On Sat, May 1, 2010 at 8:36 AM, Travis Griggs travisgriggs@gmail.comwrote:
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)
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
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
squeak-dev@lists.squeakfoundation.org