[Top][All Lists]
[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
- [Help-smalltalk] Community sprint, Luca Bruno, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Luca Bruno, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Luca Bruno, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Mike Anderson, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Bram Neijt, 2006/09/29
- Re: [Help-smalltalk] Community sprint,
Mike Anderson <=
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Mike Anderson, 2006/09/29
- Re: [Help-smalltalk] Community sprint, David Given, 2006/09/29
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/30
- Re: [Help-smalltalk] Community sprint, David Given, 2006/09/30
- Re: [Help-smalltalk] Community sprint, Mike Anderson, 2006/09/30
- Re: [Help-smalltalk] Community sprint, Paolo Bonzini, 2006/09/30
- Re: [Help-smalltalk] Community sprint, Bram Neijt, 2006/09/29
Re: [Help-smalltalk] Community sprint, Bram Neijt, 2006/09/29