On Tue, Jan 24, 2006 at 03:52:39PM -0000, Jonathan Worthington wrote:
> "Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
> >The trick is to keep references to registers in a way that notices
> >when the register set is gone, or alternatively, that keeps the
> >register set from going away. The latter is already achieved by the
> >default LexPad implementation.
>
> Looking at it, I kinda see where you're coming from, but just stashing away
> and ensuring a LexPad PMC gets marked for a long as the reference gets
> marked is not enough, as a LexPad PMC doesn't control lifetime of a context
> structure, which is responsible for the registers. OTOH, taking a closure
> does keep the context and thus register frame in place, which is perhaps
> what you meant and seems workable.
That's a clever idea, creating a closure, but closures can't achieve any
kind of weak reference. They never want to let go of their context. So
that's a non-starter.
What I had in mind, was imitating whatever a closure does to hold onto a
context chain. I would detail that here except it's not on the top of my
brain except (1) the point is the imitation-rather-than-usage strategy,
and (2) it won't work anyway, also due to the need for a weak reference.
> >Therefore, the representation of a safe pointer to a register would
> >not, in fact, be a pointer to the register's storage in memory, but
> >rather a weak reference (or, conceivably, a strong one? I doubt it)
> >plus an integer register number.
>
> A weak reference to the closure PMC, I assume?
Well, what I meant at the time was a weak reference to the context, so
when the context evaporates on its own, you can be notified. But since
contexts aren't actually GC-able yet that's pretty much impossible now.
To get what you want, you may have to introduce cheap-ass pseudo-GC
pseudo-weak-reference mechanism for contexts. For example, a list of
callbacks attached to contexts that are to be called when the context's
refcount hits zero.
I'd prefer to reuse something in the engine already for those callbacks.
If a lightweight callback mechanism, with parameter, doesn't already
exist, then you could either use a closure for -that- (eh, too expensive)
or else invent such a mechanism for general use, with yourself as first
customer.
> Ah, and the reference might not be to an integer register, but that's
> just detail...
I imagined that the references would only ever be to -PMC- registers...?
> ... the managed reference PMC will hold a reference to the array PMC
> plus the element number (or object PMC and field name). Yes,
> performance will not be amazing, but that ain't really the goal.
That's a good approach, as far as it goes. Given the amazing variety of
"array" PMCs you can't possibly guarantee that there will be a memory
address there to use, even without movement issues.
But a .Net-specific solution seems unworthy. .Net translation isn't
nearly the only code that will want mutable pseudo-references to aggregate
elements. Seems to me that aggregates should have vtable methods to
create such, with the possibility of specializing. For example, a mutable
proxy object for %ENV{$foo} would not bother with hash manipulation; it
would just call getenv() and setenv().
--
Chip Salzenberg <[EMAIL PROTECTED]>
