Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

NotFound wrote: Patches to bigint, complex, float and string applied in r31370, thanks. Thanks. There is little bit more patches. Just replacing most obvious calls. -- Bacek diff --git a/src/pmc/bigint.pmc b/src/pmc/bigint.pmc index 0c00f18..b94d513 100644 --- a/src/pmc/bigint.pmc +++

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

Thanks. There is little bit more patches. Applied in r31381, with some changes in the env.pmc part to avoid repeated calls. -- Salu2

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

Patches to bigint, complex, float and string applied in r31370, thanks. -- Salu2

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

Vasily Chekalkin wrote: And another question. Should all lvalue occurences of PMC_*_val(SELF) be replaced with VTABLE_set_*_native? (Except for VTABLE method implementation of cause) In general, yes. You'll have to check each PMC to see if they have the appropriate VTABLE_set_*(_native)

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

Hello. Another question: there is a lot of PMC_\S+_val accesses to Key pmc. Should they be replaced with VTABLE analogues as well? Or Key isn't supposed to be inherited by some other class and it will only sacrifice performance? -- Bacek.

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

On Saturday 13 September 2008 04:51:04 Vasily Chekalkin wrote: Another question: there is a lot of PMC_\S+_val accesses to Key pmc. Should they be replaced with VTABLE analogues as well? Or Key isn't supposed to be inherited by some other class and it will only sacrifice performance? The Key

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

chromatic wrote: On Saturday 13 September 2008 04:51:04 Vasily Chekalkin wrote: Another question: there is a lot of PMC_\S+_val accesses to Key pmc. Should they be replaced with VTABLE analogues as well? Or Key isn't supposed to be inherited by some other class and it will only sacrifice

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

chromatic wrote: Just for clarification, it attached patch is actually what this ticket about? Yes, that's correct. Ok, so I go ahead and try to fix more pmcs. There is single line patch for float. -- Bacek diff --git a/src/pmc/float.pmc b/src/pmc/float.pmc index d315627..fa03356 100644

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

chromatic wrote: Yes, that's correct. There is 2 patches: 1. complex.pmc single replacement of PMC_str_val. 2. string.pmc. Replaces PMC_str_val; Replace VTABLE_get_string(INTERP, SELF) with SELF.get_string(); In set_*_keyed change logick to invoke VTABLE_set_string_native instead of

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

Will Coleda wrote: Now that we can subclass PMCs with Objects, we need to go through all the code in src/pmc/*.pmc that directly fiddles with PMC guts (e.g. PMC_int_val(...) and PMC_num_val(...) and replace them with VTABLE accessor methods, or constructs like SELF.get_integer(). Just for

Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

On Thursday 11 September 2008 04:03:27 Vasily Chekalkin wrote: Will Coleda wrote: Now that we can subclass PMCs with Objects, we need to go through all the code in src/pmc/*.pmc that directly fiddles with PMC guts (e.g. PMC_int_val(...) and PMC_num_val(...) and replace them with VTABLE

[perl #56468] [TODO] use more VTABLE to avoid subclassing errors.

# New Ticket Created by Will Coleda # Please include the string: [perl #56468] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56468 Now that we can subclass PMCs with Objects, we need to go through all the code in