Re: [Help-smalltalk] Community sprint

[Paolo Bonzini]

> > > 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.
> 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.
> !
>   
<weird-idea>
Hmmmm... what about replacing the bang???

String >> #asThingumy [
  ^self shouldNotImplement
]

and

String methodsFor: 'foo' [
]

??
</weird-idea>
> > 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
> series?
>   
No, it was never added.  I have to understand the 
backwards-compatibility implications of that change...

Paolo