Spoon progress 27 July 2006: shared variables

[Craig Latta]

Hi Stef--

> Is my hypothesis really true? "is the binding (and not the class)
> stored because that way a class can be recompiled/changed and the new
> object representing the class can be changed without having to go over
> all the method literal frames?"

	Well, we could use identity-exchange ("become:") to get around that.
No, I don't think that's why classes aren't stored directly as method
literals. Associations are used for literal variables is so that the
variable itself can have a name which is distinct from the name of the
variable's value. Classes are stored in methods as literal variables
just to keep things simple (the same mechanism used to push other shared
variables is also used for pushing classes).

	Fundamentally, the key of a shared variable association (the name of a
shared variable) is provided for human convenience (in particular, so
that the system can provide readable decompiled source), not because
it's necessary for the system to run.

> ...do you only transfer method or also object?

	Spoon systems can transfer any object. In fact, this is mandatory just
to transfer methods, since method literals can potentially refer to any
object.

> Roel will start to work on a parcel like system for Squeak.

	I'm sorry to hear that. :)

> ...I do not understand why text is not good for defining classes. I
> think that relying on tools to perform extra things is fishy.

        You won't have to rely on tools for anything; you'll still be
able to do everything programmatically. I was just mentioning in passing
that there will be more convenient ways to do some things with tools.


	thanks, Stef!

-C

-- 
Craig Latta
http://netjam.org/resume