help-smalltalk
[Top][All Lists]
Advanced

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

Re: [Help-smalltalk] Re: Directions for GNU Smalltalk (was Re: [RFC] Sma


From: parasti
Subject: Re: [Help-smalltalk] Re: Directions for GNU Smalltalk (was Re: [RFC] Smalltalk scripting syntax)
Date: Mon, 19 Mar 2007 16:29:33 +0200
User-agent: Icedove 1.5.0.9 (X11/20061220)

Paolo Bonzini wrote:
> So you would be in favor of something like
> 
>     Object subclass: #Boolean.
>     Boolean instanceVariableNames: 'blah blah'.
>     Boolean poolDictionaries: 'ImportSomeNamespace'.
> 
>     Boolean methods [
>         isIdentity [ <category: 'testing'> ^true ]
>         isImmediate [ <category: 'testing'> ^true ]
>     ].
> 
> etc.?  I'm pretty sure something like this will be available "for
> free" once GNU Smalltalk's new syntax is available.

Yes, that's what I'd prefer, for the most part.  "Boolean methods [" or
something to that extent is fine, but I'm not happy about further use of
brackets.  My complaint is that they reduce readability and are a pain
to manage.  As far as I understand a method definition is introduced by
a message pattern and terminated either by some special character or a
new message pattern.  This is where I can see exclamation point being
used, the same way it's currently used after #methodsFor: to terminate a
method definition.  And as far as visual indication of where a method
definitions starts and ends is concerned, indentation does the same job
without getting in the way.  (Because most of the time you'd use
indentation anyway.)  So those definitions would look like:

    Boolean methods [
        isIdentity
            ^true!

        isImmediate
            ^true!
    ]

Or on a single line if you prefer.  I'm still not happy about <category:
''> and family either, but I suppose I can live with that.

>>> As far as scripting, your suggestions will not be implemented immediately
>>> due to lack of time, but they are a prerequisite for the next release.
>> Heh.  I do not expect anyone to immediately jump in on implementing them
>> and I'm entirely aware that they might not ever get implemented.  No
>> problem there.
> 
> I meant to say that you *can* expect them to be implemented. ;-)
> In fact, I consider your contribution to this thread to have been
> extremely useful and constructive.

Oh, that's good to read.  And thanks!

Best,
Jānis




reply via email to

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