help-smalltalk
[Top][All Lists]
Advanced

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

Re: [Help-smalltalk] Community sprint


From: Mike Anderson
Subject: Re: [Help-smalltalk] Community sprint
Date: Fri, 29 Sep 2006 14:55:18 +0000
User-agent: Mozilla Thunderbird 1.0.5 (X11/20050711)

Paolo Bonzini wrote:
> 
>>>> Class name: #Number extend: #Object [
>>>>     Method [
>>>>         isNumber
>>>>             ^true
>>>>     ]
>>>> ]
>>>>       
>>
>> There's a horrible java-smell coming off that :-b
>>   
> 
> Unfortunately I must agree that there is.  But I'm afraid that it is
> what people want.  Smalltalk has been sending messages to create classes
> for 25 years, but people still prefer language that don't.  I'm afraid
> we need syntactic sugar for them.
> 
> I'm open to suggestion on the design of this, though.

Hmm, having got over my initial wave of nausea, you may have a point
about Class >> #name:extend: (why not #name:extends: though?). I'm not
so sure about Method being stuck in there, though.

I do think that #subclass: should remain the preferred way to create
classes, though. It's standard Smalltalk (in so far as such a thing
exists), and it illustrates a few fundamental Smalltalk concepts very
nicely, specifically: everything is an object, including classes, and
everything is done by sending messages to objects. Realizing that
classes were created by sending a message to another class was one of my
"Wow!" moments when learning Smalltalk.

> <weird-idea>
> Hmmmm... what about replacing the bang???
> 
> String >> #asThingumy [
>   ^self shouldNotImplement
> ]
> 
> and
> 
> String methodsFor: 'foo' [
> ]
> 
> ??
> </weird-idea>

I was warming to the first one. It looks like you're sending a block as
a message, which is odd, but not too odd. To think of a method body as a
block is very natural. Unfortunately, I've realized that it gives you no
opportunity to name the parameters. I suppose you could have:

String >> [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
]

I don't think that the #methodsFor: case works so well. There's less
justification for having a special-case block:

String methodsFor: 'text processing' [
  [ split: aSubString
    "Create a collection of my sub strings delimited by aSubString."
  ].
  [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
  ]
]

Personally, I wouldn't mind declaring the category for each method:

String methodFor: 'examples' body: [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
]

Mike




reply via email to

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