Warning, long post. I haven't written it yet, but I get this feeling...

Ian Piumarta wrote:

> [snip]
> The focus has changed.  Forget any preconceived ideas about the
> underlying mechanisms (class-instance/prototypes,
> inheritance/delegation, whatever) and concentrate instead on the
> mechanisms for describing the guiding principles: the (static and
> dynamic) nature of objects themselves.  This is what should be made as
> simple and intuitive as possible, after which it should hopefully be
> trivial to make anything you want out of an object, its behaviour, and
> the mechanisms that you might dream up to organise, use and reuse such
> within the system.

I think, but am not sure, I get your meaning. Can you give me an example?
What do you mean by a mechanism for describing the static and dynamic nature
of objects?
Something like - "objects live as long as they are referenced (or maybe a
little after)" described by the nature of garbage collection (a very implicit
and untouchable mechanism, right now...)?

> > How otherwise can you change the messaging part?
> Yup.

> > What am I missing?
> Not much, by the looks of things. ;)

Well, I'm not sure. It seemed (to me) like Alan was saying that we CAN change
what messaging means WITHOUT talking about the objects. Which sure sounds
strange and new to me.

> (Aside: Whatever happened to that stuff in Smalltalk-7[insert smallish
> numeral here], where each object "parsed" the next element(s) in the
> program to decide how to respond?  I thought that was rather neat!)

I think it was "prematurely optimised" into the VM, so we won't need noise
cones on our Squeaky PDAs... ;-)
I'd love to see that too, actually. We could simulate it inside the image,
just to play. Anyone have
pertinent docs?
(or remembers how they did it, 20 years after the fact? ;-)

> The Common Lisp MOP was a step in the right direction, but now we have
> an opportunity that was missing in most previous work: we are at
> liberty to change *any* part of the existing system to accomodate a
> better/simpler/more intuitive MOP.  Backwards compatibility is not a
> prerequisite for any future direction.

Be practical (or enlighten me) - we want to keep the major parts of the system
working. Especially the
new and cool stuff, like morphic. In order for it to stay Squeak, it pretty
much has to stay short-term
backwards compatible, or be easy to port to.
Suddenly changing the whole basis of Squeak might not be trivial...

> > it seems hard to me to explain why blocks and compiled methods are
> > separate things.  aClass execute: aBlock when: aSelector seems like
> > a very natural way to add behavior too, and would eliminate a
> > concept in the language.
>
> "Crystalisation of style" is the accepted term, I think. ;) ;)

I suggest we find as many of these things (system level operations that are
now complex and can be
made simple) as we can, and change them. Now. IMHO, the bang per buck ratio
will be bigger than for killing
the prime anomaly. Think of the effect when a newbie first goes into the
Browser code for accepting changes
and sees the current code for invoking the compiler ("ok, lots of things are
simple, but I shouldn't get carried
away..."). We should do our best to cause that response's extinction.


> > This would require something like the class explicitly binding the
> > block to itself after the block's creation.
> > But that's a relatively deep change.
> Not really.

Depends who's holding the meter, I guess ;-)

> Take a look at the implementation of primitivePerform and
> primitiveValue in the VM.  They're strikingly similar.  With proper
> closure semantics (there's new movement in this direction, BTW) for
> blocks, these two operations become even more similar.

The similarity is there. But one difference that stays put is that blocks are
supposed to bind to the context of their
creation (and only that), and CompiledMethods are supposed to bind to the
class to which they belong (a different
sort of binding - instance vars aren't temps, and self isn't supposed to bind
at all until runtime).
The runtime constructs can probably be unified with too much difficulty (if
you say so), but we'll need new syntax
for "not yet bound blocks".


> If blocks were
> extended with the possibility of "primitive response" then any
> remaining differences would be utterly insignificant.

What do you mean by primitive response? implementation by a primitive
(w/possibility for primitive failure?

> So MethodDictionaries bind selectors to closures, and my intuition
> screams at me that the "performance problems" are trivial to solve
> entirely within the execution mechanism -- there's no need to weaken
> in any way whatsoever this little crystal of style that you just grew
> in the "programmer's universe".

Do you think the problems (including what I raised above) can be solved? It
would be cool...
If not, I think we can fallback on having classes install a string (basically,
just pushing the compilation into the class,
and out of the users mind).

BTW, having the class compile it's own methods might have interesting
benefits. A class might want to do something other
than to compile it's method traditionally.