Dan Sugalski wrote:
Since we're running into Ponie issues with this, which means we'll run
into Apache issues as well as any number of other systems
When Parrot's being embedded I can see the following functions needing
overriding by the embedder:
*) Memory: malloc, realloc, calloc, free
*)
Dan Sugalski wrote:
Okay, time to think about this.
We need the ability to layer PMCs. Nothing new, we need something of the
sort for transparent read-only-ness and probably thread-safety (though
we don't have to do it that way) and folks are going to want to do
undoable custom vtable layering.
Dan Sugalski wrote:
[sniping to reduce verbiage]
The issue is that the PMC's original vtable assumes (and should, IMHO
be _able_ to assume) that it has total control over the PMC's data,
Well... I think I'll disagree here. The *class* vtable can assume this.
However that doesn't mean that any r
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an example of
when you'd want to be
Thusly did Dan Sugalski inscribe:
At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtabl
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtable has a link to the next in
the chain. It *also* means that each call into a vtable function
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my
head for a while, I came to the conclusion that namespaces are not
conceptually hierarch
