At 10:54 AM -0500 1/23/04, Benjamin Kojm Stuhl wrote:
Well, that was why I had my suggested sample pseudocode restore the
previous vtable pointer before calling down to the next function
(and put itself back when that's done).
That has reentrancy issues, unfortunately. Potentially threading and
-Original Message-
> Date: Fri Jan 23 09:27:12 EST 2004
> From: "Dan Sugalski" <[EMAIL PROTECTED]>
> At 10:37 PM -0500 1/22/04, Benjamin K. Stuhl wrote:
> >Dan Sugalski wrote:
> >>In addition to the thread autolocking front end and debugging front
> >>end vtable functions, both of which ca
At 10:37 PM -0500 1/22/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
In addition to the thread autolocking front end and debugging front
end vtable functions, both of which can be generic, there's the
potential for tracing and auditing front end functions, input data
massaging wrappers, and a
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
At 8:37 AM -0500 1/19/04, Benjamin K. Stuhl wrote:
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 exampl
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 able to do that... After
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 able to do that... After all, since o
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 vtable has a
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 vtable has a link to the next
in the chain. It
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
At 11:53 AM +0100 1/16/04, Leopold Toetsch wrote:
PMCs use Vtables for almost all their functionality *and* for stuff
that in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps
in the Const$PMC vtable, where all vtable methods that
11 matches
Mail list logo
