On Friday 05 July 2002 13:27, Alan Kay wrote:
>       On this list, I've mentioned several times that variables and
> instances should be objectified. This has been done in several other
> systems to provide much better leverage on a number of important
> problems.

I don't know what you mean by objectified instances, but had an 
interesting idea on how to deal with variables. I borrowed the term 
"slices" from ZX81 Basic, but the inspiration was mostly from APL.

A slice would be related to a part of an object (or a parts of several 
objects) in a similar way that a stream is related to its collection. 
So if I create

     s := ArraySlice on: #(6 5 4 3 2 1 0) from: 2 to: 4

then I could do something like

            s put: 9

and have #(6 9 9 9 2 1 0) as a result. This might also be interesting

         v := VariableSlice on: 7 at 8 named: #y

And we should be able to combine slices in various neat ways. The 
original idea was more as a GUI level device and David Ungar has 
recently partly implemented this in Self. There is a little more about 
slices at http://www.lsi.usp.br/~jecel/tech.html

>       Messages and message sending could be more objectified. This
> would allow a much more flexible approach to trying delegation
> schemes, finding alternatives to inheritance, etc.
>       Another larger area that I'm astounded that no grad student has
> done a thesis on, would be to take the "Smalltalk VM in itself" that
> we use for bootstrapping, and make it into a real OOP model itself. A
> large part of this is just to restructure the messy workable thing we
> have now.

My Ecoop95 paper (http://www.lsi.usp.br/~jecel/jabs7.html with a later 
version published as a chapter in a book) was exactly about this. If 
you find that grad student in the next few months, have him (is it ever 
a "her" in this field?) talk to me.

>      Methods could stand to be more objectified. I'd like to see
> methods that have a vertical bar down the middle. On the left would
> be the "reference code": the simplest code that does what the method
> should do. On the right would be the "pragmatic code": a bunch of
> cases for running the meaning efficiently. You should be able to run
> both sides when debugging, etc.

One big difference between the reference code and the pragmatic code is 
the cacheing of results. Up to a certain point it would be possible to 
transform the former into the latter by adding annotations for a "cache 
manager". I have more details about this in the same page that talks 
about slices.

>      Another method objectification would be to have many polymorphic
> methods be instances of a class that guards the meaning of the
> polymorphism. This is part of having a model for both variables and
> "slots", etc.

In the CoDA reflective Smalltalk system, this would be handled by 
replacing an object's default Protocol meta-object.

>       One way to play with this would be to just take the three
> "principles" above and make a complete model. This is pretty easy.
> The important thing that CLOS (e.g.) did was to make the additions to
> the models compilable so that metachanges could be as efficient as
> the kernel. We kind of have this with SLANG, but the whole apparatus
> could be much much cleaner.

A Jitter in Smalltalk would do the job.

-- Jecel