[Top][All Lists]

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

Re: [Help-smalltalk] Community sprint

From: Paolo Bonzini
Subject: Re: [Help-smalltalk] Community sprint
Date: Fri, 29 Sep 2006 14:27:04 +0200
User-agent: Thunderbird (Macintosh/20060909)

Class name: #Number extend: #Object [
    Method [
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.
Also, that syntax suggests that the methods of a class have to be
declared when the class itself is declared, but one of the ways in which
Smalltalk wins big is that you can add/change methods in
already-declared classes (and change their declaration, but I don't find
the need to do that so often).
I think Luca's example (and my Java-smelling example) could be extended pretty easily (though in Luca's case, the doubling of string quotes is just wrong).
I actually quite like the file-out format (maybe it's just that I've
done a lot of coding in it),
Me too, for that matters.
Writing this, I did wonder if it would be nice for #>> itself to switch
to method compilation mode for one method only if the method is not
already present:

String >> #asThingumy !
        ^self shouldNotImplement.

String >> #asBob !
        ^self subclassResponsibility.
Hmmmm... what about replacing the bang???

String >> #asThingumy [
  ^self shouldNotImplement


String methodsFor: 'foo' [

Also, i see in Squeak that #new calls #initialize, i don't see this
behavior here, what about?
I thought that got added a while back. Did it not make it to the stable
No, it was never added. I have to understand the backwards-compatibility implications of that change...


reply via email to

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