On 5/11/07, Alek Storm <[EMAIL PROTECTED]> wrote:
Whew. Thanks for looking over my giant patch :). I've split the original
patch into three parts - testing, specs, and code, and rebased it on
r18494. I've also cut out the code that modified the implementation of
invoke() in the old object sys
On 5/8/07, Allison Randal <[EMAIL PROTECTED]> wrote:
I actually changed every instance of 'vtable method' to 'vtable
function' a few days ago to help clear up the confusion. (A vtable
function does have an invocant 'self' but doesn't act as a method in any
other way.) But, while I was adding the
Alek Storm wrote:
Attached a patch to bring that in line with the
rest of the patch, and also to s/vtable function/vtable method/gi. In
addition, a vtable method ISA method; it's just not returned by
'find_method'.
I actually changed every instance of 'vtable method' to 'vtable
function'
Will Coleda wrote:
If we're keeping :vtable, we need to update this verbiage (and include
an example) to avoid confusion.
On a related note, :method is mentioned in docs/compiler_faq.pod &
docs/imcc/calling_conventions.pod. If it's dead, it needs to be
deprecated; if it's not, it should pro
On 5/9/07, Will Coleda <[EMAIL PROTECTED]> wrote:
Looking at PDD15, I see this paragraph...
> To override a vtable function, either add the :vtable pragma to the
> declaration of the method, or pass a named parameter "vtable" into
the
> add_method method on a class or role.
... which is kind of
On general development styles, you've altered the spec, the tests, and
the code all in one massive patch. It's better to make changes in
smaller steps. That gives the whole list an opportunity to discuss the
changes, and accept or reject individual components.
If you have spec changes, it's be
On Tuesday 08 May 2007 15:02:34 Alek Storm wrote:
> No, with :vtable you define a sub of any name and use the :vtable
> attribute, specifying which vtable method it overrides if the name doesn't
> match the vtable name. Then you create a Class PMC and call 'add_method'
> on it, passing the name,
On May 8, 2007, at 6:02 PM, Alek Storm wrote:
On 5/8/07, chromatic <[EMAIL PROTECTED]> wrote:
With :vtable, you define a sub of the appropriate name and use
the :vtable
attribute.
Without :vtable, you define a sub of any name, add :anon so as not to
pollute
your namespace, somehow magical
On 5/8/07, chromatic <[EMAIL PROTECTED]> wrote:
With :vtable, you define a sub of the appropriate name and use the :vtable
attribute.
Without :vtable, you define a sub of any name, add :anon so as not to
pollute
your namespace, somehow magically get that sub in a PMC, get the
appropriate
class
On Tuesday 08 May 2007 13:38:31 Alek Storm wrote:
> It works exactly the same way as 'add_method' - this is the way the new
> object system works, as defined in PDD15. Since this makes :vtable
> pointless, I think we should get rid of it.
With :vtable, you define a sub of the appropriate name an
On 5/8/07, Will Coleda <[EMAIL PROTECTED]> wrote:
How would one implement a vtable method, (referring to self), and then add
it to the object? You'd have to add an ":init :load :anon" block after the
vtable was defined in order to invoke add_vtable_method, and you'd need a
reference to the invo
Alek Storm (via RT) writes:
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42905 >
I've attached a patch to implement vtable overriding for
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42905 >
I've attached a patch to implement vtable overriding for PDD15. The basic
idea is to wr
13 matches
Mail list logo
