Smalltalk › Squeak › Squeak - Dev

The Inbox: Morphic-phite.429.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

65 messages Options

1234

Ralph Johnson

Re: <Method Tags> (Pragmas)

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

hernanmd

Re: <Method Tags> (Pragmas)

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 <[hidden email]>

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

Eliot Miranda-2

Re: <Method Tags> (Pragmas)

In reply to this post by Travis Griggs-4

On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <[hidden email]> 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 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...

Hannes Hirzel

Re: <Method Tags> (Pragmas)

On 5/3/10, Eliot Miranda <[hidden email]> wrote:
> On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <[hidden email]>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)

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

Eliot Miranda-2

Re: <Method Tags> (Pragmas)

On Tue, May 4, 2010 at 2:07 PM, Hannes Hirzel <[hidden email]> wrote:

On 5/3/10, Eliot Miranda <[hidden email]> wrote:

> On Sat, May 1, 2010 at 8:36 AM, Travis Griggs <[hidden email]>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

1234