Vassili Bykov wrote:

> First of all, let me apologize if what I am about to propose sounds
> sarcastic with respect to an earlier post on this list.  I am not making an
> evil fun of David's post.  (Yes, so far I AM serious).
>
> Second, I must confess that this idea came to me while I was under the
> influence of the recent events at the company I work for.  The substance in
> question is described on our excellent webpage "www.objectpeople.com".  I do
> NOT strongly recommend that anyone reads it, unless you want to know why I
> wanted to lighten up.
>
> Now, to the heart of the matter: I have realized how Objects can be removed
> as a language construct in Smalltalk without giving up functionality of
> power of expression.
>
> Why remove Objects?  Objects have long been one of my biggest qualms with
> Smalltalk (perhaps second only to the lack of continuations). I am sure that
> my original uneasiness came from having to get used to the weird variable
> binding and method lookup constructs. But even once I was used to 'Object
> subclass: #MyClass instanceVariableNames: '...' ...' and thought it was so
> cool that methods could me invoked, on demand, by simply sending messages, I
> was still not entirely convinced that Objects were The Right Thing To Do.
>
> Then, last night, in less than an hour after we had just finished a staff
> meeting it hit me: Objects are almost always unique structural units by
> virtue of grouping variable bindings and methods. But Smalltalk already has
> a mechanism for creating new structural units by grouping variable bindings;
> it is called a BlockClosure. Having two ways to do the same thing violates
> the principle of monotony. As soon as my beef with Objects was expressed in
> these terms, I knew for certain that 1) Objects had to go and 2) they could
> be replaced with regular block closures and block closure invocations and
> not be missed.
>
> To put what I've just said into a (kind of) concrete example, what I am
> proposing is the following:
>
> WITH OBJECTS
>
> Object subclass: #Car
>         instanceVariableNames: 'speed'
>         classVariableNames: ''
>         poolDictionaries: '' !
>
> ! Car methods !
>
> speed
>         ^speed !
>
> speed: aNumber
>         speed := aNumber !
>
> stop
>         speed := 0 ! !
>
> WITHOUT OBJECTS
>
> Car := [ | speed |
>        speed := 0.
>         [:message |
>           #speed == message
>             ifTrue: [[speed]]
>             ifFalse: [#speed: == message
>               ifTrue: [[:newSpeed | speed := newSpeed]]
>               ifFalse: [#stop == message
>                ifTrue: [[speed := 0]]
>                ifFalse: [self error: 'MessageNotUnderstood', message]]]]]
>
> <CREATING AN INSTANCE>
>
> aCar := Car value.
>
> <SENDING MESSAGES>
>
> (aCar value: #speed:) value: 65.  "aCar speed: 65"
> (aCar value: #speed) value.       "aCar speed"
> (aCar value: #stop) value.        "aCar stop"
>
> To try and explain my idea one more time, all I have done is: 1) put the
> methods formly grouped in the Object into their own closures. 2) Explicitly
> implemented closure look-up. 3) Invoked a closure instead of sending a
> message.
>
> I don't see anything that cannot be done with this scheme that can be done
> with objects. The advantage is that the language is now simpler, having
> removed a construct that, in the final analysis, didn't really contribute
> anything.   The biggest drawback that I can see to this is that users who
> were presented with the change but not the rationale would probably not
> think to make a new closure to take the place of the method grouping that
> would have been put inside the class.
>
> Well, I hope I have explained my idea clearly enough. Let me know what you
> think. I, for one, am estatic; I've finally figured out why I've always
> been uncomfortable with objects and how I can get rid of them! At least,
> until someone bursts my bubble. :)
>
> --Vassili

Vassili,

This is one of the sweetest posts I have ever seen. Goes right up there with
Steele's talk at OOPSLA '98 in artfulness. Got a good laugh out of it.

--
Travis Griggs (a.k.a. Lord of the Fries)
Member, Fravenic Skreiggser Software Collective
Key Technology
P-P-P-Penguin  Power!