The Inbox: Morphic-phite.429.mcz
Locked
1234
1234
 
|
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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 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 <[hidden email]> wrote: > Weighing in on a 2 day dead topic is probably passe` around here... :) > > I can weigh in with some practical/historical experience from > VisualWorks land, where they originated. > > 1) We use them more and more. But judiciously. What they are really > good for is defining programatic categorization of methods, so that > one can discover programatically subsets of behavior that a given > Behavior implements. Examples include the obvious <settings..> and > <menu..> sort of things. We use them in the RefactoringBrowser to make > certain aspect easily pluggable, such as adding your own tool pane, > navigator pane, or status pane. The inspector uses them to support > arbitrary inspector fields on any object. We even use them in <test>s, > because I've found that you tend to make better test selector names, > when your brain isn't trying to negotiate coming up with a good > selector name that describes what your test does AND begins with the 4 > characters 'test'. I used them in production code more and more when I > was at Key writing UIs and control systems for optical food sorting > equipment. > > Why not just use a method categories (protocols)? Because you can't > quite put enough information there to make them useful, and they're > stuck with just one category. You want simplicity and judicious > application, deferring to good ol' messages as much as possible, but > simple categories just don't provide enough. > > 2) I push, at ever juncture I can, the term <tagged methods> and > <method tags>. The <tag> term grew on me for a set of reasons. > Technically, they result in "AnnotatedMethods", and one can call each > item an "Annotation". But that's a big long word, and using small > short words always keeps things simpler. I also liked the harmony with > the fact that we live in a world dominated by <tag><markup><languages> > and they're called tags there. Since we were using roughly the same > syntax, why not go with it? It's also easier to draw an icon that > shows up next to methods for <tagged methods> than it is for > <annotated methods> (see attached pic). > > 3) You can get carried away with <method tags>. It's tempting to grow > little micro-DSLs with these things. They don't scale well for that. > They're far from turing complete, and you're limited to literal > objects. Best example of this is the nightmare that the method tags > for menus were turning into VW. I wrote about this here: > > http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 > > 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 > > |
|
|
Good reminder, Travis.
> 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. |
|
|
2010/4/30 Steve Wessels <[hidden email]>:
> 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. > > > |
|
|
In reply to this post by Travis Griggs-4
On 4/29/2010 1:23 PM, Travis Griggs wrote:
> Weighing in on a 2 day dead topic is probably passe` around here... :) It's not quite dead yet :-) > 2) I push, at ever juncture I can, the term <tagged methods> and <method > tags>. The <tag> term grew on me for a set of reasons. I think that's a great term. It doesn't have the compiler connotations of "pragma", is shorter than "annotation" yet very concise and flexible. I like the sound of, e.g., "the apicall tag instructs the compiler to generate the code for some FFI call", "the preference tag allows discovery of preferences", the "type tag can be used to annotate variables". It really works for me. In fact, I raise my hand and vote for renaming Pragma to MethodTag :-) > 3) You can get carried away with <method tags>. It's tempting to grow > little micro-DSLs with these things. They don't scale well for that. > They're far from turing complete, and you're limited to literal objects. > Best example of this is the nightmare that the method tags for menus > were turning into VW. I wrote about this here: > > http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 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-discovery/ 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 :-) > >> 2) I push, at ever juncture I can, the term <tagged methods> and >> <method >> tags>. The <tag> term grew on me for a set of reasons. > > I think that's a great term. It doesn't have the compiler > connotations of "pragma", is shorter than "annotation" yet very > concise and flexible. I like the sound of, e.g., "the apicall tag > instructs the compiler to generate the code for some FFI call", "the > preference tag allows discovery of preferences", the "type tag can > be used to annotate variables". It really works for me. > > In fact, I raise my hand and vote for renaming Pragma to MethodTag :-) > >> 3) You can get carried away with <method tags>. It's tempting to grow >> little micro-DSLs with these things. They don't scale well for that. >> They're far from turing complete, and you're limited to literal >> objects. >> Best example of this is the nightmare that the method tags for menus >> were turning into VW. I wrote about this here: >> >> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 > > 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-discovery/ 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." |
Re: <Method Tags> (Pragmas)
|
|
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 <[hidden email]> wrote:
-- Casey Ransberger |
|
|
In reply to this post by Andreas.Raab
On 30.04.2010, at 05:23, Andreas Raab wrote:
> > On 4/29/2010 1:23 PM, Travis Griggs wrote: >> 2) I push, at ever juncture I can, the term <tagged methods> and <method >> tags>. The <tag> term grew on me for a set of reasons. > > I think that's a great term. It doesn't have the compiler connotations of "pragma", is shorter than "annotation" yet very concise and flexible. I like the sound of, e.g., "the apicall tag instructs the compiler to generate the code for some FFI call", "the preference tag allows discovery of preferences", the "type tag can be used to annotate variables". It really works for me. > > In fact, I raise my hand and vote for renaming Pragma to MethodTag :-) +1 Thanks Travis! - Bert - |
|
|
On 4/30/10, Bert Freudenberg <[hidden email]> wrote:
> On 30.04.2010, at 05:23, Andreas Raab wrote: >> >> On 4/29/2010 1:23 PM, Travis Griggs wrote: >>> 2) I push, at ever juncture I can, the term <tagged methods> and <method >>> tags>. The <tag> term grew on me for a set of reasons. >> >> I think that's a great term. It doesn't have the compiler connotations of >> "pragma", is shorter than "annotation" yet very concise and flexible. I >> like the sound of, e.g., "the apicall tag instructs the compiler to >> generate the code for some FFI call", "the preference tag allows discovery >> of preferences", the "type tag can be used to annotate variables". It >> really works for me. >> >> In fact, I raise my hand and vote for renaming Pragma to MethodTag :-) > > +1 > > Thanks Travis! > > - Bert - +1 --Hannes |
|
|
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 <[hidden email]> wrote: > On 4/30/10, Bert Freudenberg <[hidden email]> wrote: >> On 30.04.2010, at 05:23, Andreas Raab wrote: >>> >>> On 4/29/2010 1:23 PM, Travis Griggs wrote: >>>> 2) I push, at ever juncture I can, the term <tagged methods> and >>>> <method >>>> tags>. The <tag> term grew on me for a set of reasons. >>> >>> I think that's a great term. It doesn't have the compiler connotations >>> of >>> "pragma", is shorter than "annotation" yet very concise and flexible. I >>> like the sound of, e.g., "the apicall tag instructs the compiler to >>> generate the code for some FFI call", "the preference tag allows >>> discovery >>> of preferences", the "type tag can be used to annotate variables". It >>> really works for me. >>> >>> In fact, I raise my hand and vote for renaming Pragma to MethodTag :-) >> >> +1 >> >> Thanks Travis! >> >> - Bert - > > +1 > > --Hannes > |
|
|
In reply to this post by Travis Griggs-4
On Fri, Apr 30, 2010 at 2:00 AM, Travis Griggs <[hidden email]> wrote:
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 |
|
|
In reply to this post by Travis Griggs-4
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 <[hidden email]>: > 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 > > 4) History repeats itself, I think I wrote a post along these lines, about > 3+ years ago. I've slept since then tho, so I'm not sure. > > -- > Travis Griggs > Objologist > "The best way to know you have a mind is to change it" -Judge Pierre Leval > > > > > > > > |
|
|
The <...> 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 <[hidden email]> 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 <[hidden email]>: >> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >> >> 4) History repeats itself, I think I wrote a post along these lines, about >> 3+ years ago. I've slept since then tho, so I'm not sure. >> >> -- >> Travis Griggs >> Objologist >> "The best way to know you have a mind is to change it" -Judge Pierre Leval >> >> >> >> >> >> >> >> > > |
|
|
The mechanism to discover preferences in method tags <pragma> is in the class
Preferences , class side , category 'dynamic preferences' , method preference: prefName category: aCategory description: helpString type: typeSymbol Then look for senders of this method. This gives you the methods with this tag in it. (38 so far, i.e. the process has just started) --Hannes On 4/30/10, Hannes Hirzel <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >>> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >>> >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >> >> > |
|
|
In reply to this post by Hannes Hirzel
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 <[hidden email]>: > 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 <[hidden email]> 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 <[hidden email]>: >>> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >>> >>> 4) History repeats itself, I think I wrote a post along these lines, about >>> 3+ years ago. I've slept since then tho, so I'm not sure. >>> >>> -- >>> Travis Griggs >>> Objologist >>> "The best way to know you have a mind is to change it" -Judge Pierre Leval >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > |
|
|
What I have understood so far is that these method tags help to
decouple things. Instead of my package having to do something (e.g. registering a preference) the base system "discovers" the preference settings of my package. --Hannes On 4/30/10, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>: >> 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 <[hidden email]> 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 <[hidden email]>: >>>> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > |
|
|
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 <[hidden email]>: > 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 <[hidden email]> 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 <[hidden email]>: >>> 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 <[hidden email]> 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 <[hidden email]>: >>>>> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >>>>> >>>>> 4) History repeats itself, I think I wrote a post along these lines, >>>>> about >>>>> 3+ years ago. I've slept since then tho, so I'm not sure. >>>>> >>>>> -- >>>>> Travis Griggs >>>>> Objologist >>>>> "The best way to know you have a mind is to change it" -Judge Pierre >>>>> Leval >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
|
|
Actually this <cool thing> has been around for a long time in
VisualWorks and Travis refers to the experience with that in this thread. May I ask you to go to the blog entry he refers to. In fact if we go for this as well it should avoid these pitfalls.... --Hannes On 4/30/10, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>: >> 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 <[hidden email]> 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 <[hidden email]>: >>>> 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 <[hidden email]> 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 <[hidden email]>: >>>>>> 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&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
|
|
In reply to this post by hernanmd
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 <[hidden email]>: > 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... > > > > > > |
|
|
In reply to this post by Travis Griggs-4
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |