I was thinking that handle may be a capability ref, mutable in the scope of the ref state machine.

Thank you,
Robert


On Jan 28, 2014, at 2:36 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 
> 
> 
>> On Tue, Jan 28, 2014 at 1:08 PM, Colin Putney <colin at wiresong.com> wrote:
>> On Tue, Jan 28, 2014 at 3:54 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> > https://plus.google.com/+KentonVarda/posts/GRJ4h4w2UN9?  Or am I being
>> > cynical?
>> 
>> Yeah, I think that's what he was talking about. It's hard to see how
>> dynamic languages could use Cap'n Proto, because they don't tend to
>> give enough low-level control over memory layout in the heap.
> 
> Wouldn't pinning be enough?  No, because one needs to intermix binary data and objects.  But if one added a ref type, or some object handle type, so there's just one level of indirection from a handle in the protobuf and an object, that might get far enough no?
> 
> The alternative would be to add struct support to Spur which might be doable.  But it's a lot of work for a rather specific application.  Anyway, I'm open to others experimenting on this.
> 
> Reminds me of work Tony Mann at Harlequin did or described to me, which again is reminiscent of Digitalk's object layout.  The idea is to have the class reference in an object (even if this is an index into a table) not point directly to the class object, but to refer to some intermediate, possibly hidden, structure.
> 
> In The Harlequin case this structure included code that would be run by the GC to traverse the object, which is how the system supports heterogenous structures, and saves on a size field (except for variable-sized objects).
> 
> In the Digitalk case the structure is a method dictionary, which allows the system to support easily instance-specific behaviours.  (Forgive the digression).
> -- 
> best,
> Eliot
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140128/df778405/attachment.htm