On Wed, Jul 8, 2009 at 2:30 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
> ur original message wasn't clear on the subject) that what you do when you
> want to reuse one of these closures is that you copy the closure and its
> enclosing MethodContext (remember this is a chain and blocks could be
> nested) and assign the new receiver in the copy.  That's not too bad but its
> still very heavyweight because you're not sharing code between instances.
>

No I actually am using the chain as is, and counting on the fact that these
blocks are nested.   The only tricksy bit is
you can't actually use ^ in the BlockClosures or you run into the sender's
context no longer exists error :)  I'm exploiting
the fact that you can hard ref them, and keep the garbage collector from
scavaging them.


> But you don't need to copy the MethodDictionaries.  With the above approach
> they're shared/inherited.  So when a message is sent to a subinstance the
> lookup machinery will follow the prototype chain until it finds a method or
> triggers dNU.
>

Ah that's one thing I need to explain.  There's no prototype chain!   Each
object is standalone with copies of closures from 2 or more objects.  Some
of those closures are actually generated on the fly, and orphaned from their
original context.  Prototyping doesn't work, when you need partial
inheritance from multiple objects!

For example, I have a method called "which:" which performs a test upon each
property of an object, and returns a new
object instance with only those properties.  Often I use this to do things
like take the intersection of two objects, ie inherit those properties which
are common to two arbitrary parents, and then extend using a 3rd archetype.

So I actually do need to copy MethodDictionaries, as objects often alter
their own and others periodically at runtime.  For example, the
implementation of a method #draw may change over time, as an animation timer
swaps out new
BlockClosures for each frame in the animation.  Some times the #down event
that is dispatch to all widgets get replace based on the application state,
rather than performing checks within the method.


>  In the activation self is bound to the original receiver.  The issue is
> hence making sure that slot layouts in subinstances match their parents so
> that parent methods work correctly on subinstances.  But that's not a new
> problem, Smalltalk does exactly that :)
>

Yeah, that becomes a huge problem, as I often remove slots from children
that exist in the parent objects.  And since
these are ad hoc objects, there's no set relationship between parent and
child.  An object may derive from one object,
and then at a later date, serve as reference for the object that was its
parent, such as:

A -> B -> C
              &D -> A

A is now A's own great
grandson.  B doesn't however derive any changes from C, as it has its
own copy of each property.

The Javascript version of this code doesn't even use prototype based
inheritance!  The idea behind this sort of
unstructured Object Oriented programming is "object sex".    You treat each
object as a stand alone entity, that
can swap out its genes with other objects as necessary.  So it isn't
"prototype" based in the traditional sense, it
is more archetype based with ad hoc morphology.


> Please keep me in the loop.  This is interesting and I'm happy to review.
>

Very cool, will do!

Dave
-- 
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090708/191926d0/attachment.htm