On Friday 05 July 2002 13:27, Alan Kay wrote:
On this list, I've mentioned several times that variables andinstances 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@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. Thiswould 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 seemethods 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 polymorphicmethods 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