help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] [RFC] Smalltalk scripting syntax
Date: Tue, 13 Mar 2007 07:22:50 +0100
User-agent: Thunderbird 1.5.0.10 (Macintosh/20070221)

>> I don't want to transform Smalltalk into something else, I just think
>> that its strength is in the language and in the class library, not in
>> using message sends to define classes and methods.
> 
> I disagree: I think that its strength (one of many) lies in the
> consistency of the language - everything is (or can be) accomplished by
> message sends. I don't like magic in the compiler.

That's why I carried it over to the point where there is magic in
the parser and not in the compiler.  But I see your point.

OTOH, the parser *will* use message sends to define classes and
methods.  This is not going to go away, obviously.

>> An alternative possibility could be:
>>
>>     SomeClass >> `(printOn: aStream) defineAs: [ :aStream |
>>     ]
> 
> This step starts to bother me: the CompiledMethod (SomeClass >>
> #printOn:) has been created before it has been defined. That wasn't true
> in the previous step.

Not necessarily.  The fictional `(printOn: aStream) is not a Symbol.
One can use double dispatch to return a "CompilationEnvironment" object,
or something like that.

But this is all fictional indeed.  While the description was meant
to derive the intended syntax from purely Smalltalk syntax, it is
worth noting that even the first example,

    SomeClass define: `(printOn: aStream) as: [ :aStream |
    ]

cannot be implemented without modifying the compiler---and not because
of `(...)!  The instance variables of SomeClass should somehow be in
scope when processing the block, and that's not something that is
supported in standard Smalltalk.  And that's why it's in the end
simpler to go all down the road to

    printOn: aStream [
        body
    ]


> In fact, with scoped definitions it seems to me that all of the
> preceding arguments are moot.

They still give a rationale for the intended shortcut syntax to define
methods in other classes and as class methods, like

   ...
   isString [ ^true ]

   "Object must be a superclass of the current scope"
   Object >> isString [ ^false ]

>> If you would tell me which step bothers you the most, that could help
>> a lot.
> 
> Actually, in spite of my comments, I *don't* have much of a problem with
> instance variables or instance methods at all. What bothers me is the
> class scoping and the class variables.
> 
> What about declaring class variables using | | inside the class scope?

I answer parasti about that.  Suggestions are welcome about class
scoping improvements.  In particular, in what way does it bother you?

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]