Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> OTOH, if there is a clear need for an e.g. NumStr hybrid, then it
>> should be a separate PMC which is used, when $HL says so by some
>> traits.
> There is indeed a clear need for it -- the values produced by $! (and by
> the
On Fri, Jul 11, 2003 at 04:20:34PM -0400, Chip Salzenberg wrote:
> According to Benjamin Goldberg:
> > There is indeed a clear need for it ...
>
> False.
>
> > We don't *need* to do things this way, of course ...
>
> True.
>
> Having gone through the pain of numstr implementation, I suggest tha
Benjamin Goldberg:
# There is indeed a clear need for it -- the values produced by $! (and
by
# the related $^E) are dual int/string values.
In Perl 5, yes. However, in Perl 6, $! is set for *all* exceptions, not
just C errors, so I suspect that this behavior is no longer
appropriate. (IIRC, C e
According to Benjamin Goldberg:
> There is indeed a clear need for it ...
False.
> We don't *need* to do things this way, of course ...
True.
Having gone through the pain of numstr implementation, I suggest that
normal variables should not be forced to do anything so unnatural.
(Customized PMCs
Leopold Toetsch wrote:
> Nick Glencross wrote:
>
> > Having read up in the past on Perl5 internals, it seems to be
> > capable of keeping more than one representation of a Scalar active
> > at a time.
> >
> > Anyone know if there are plans to do this kind of optimisation?
>
> I don't think, this
Nick Glencross wrote:
Having read up in the past on Perl5 internals, it seems to be capable of
keeping more than one representation of a Scalar active at a time.
Anyone know if there are plans to do this kind of optimisation?
I don't think, this is an optimization at least not for an average
Luke Palmer wrote:
The way I see this being done is by adding another level of
indirection. PerlScalar would implement its polymorphic behavior in
the set_* methods, and delegate everything else to its "contained"
pmc.
Having read up in the past on Perl5 internals, it seems to be capable of
keep
Luke Palmer wrote:
Going about (finally) implementing my Infinity pmc, I noticed a lot of
redundant code in the Perl* classes.
[ ... ]
The way I see this being done is by adding another level of
indirection. PerlScalar would implement its polymorphic behavior in
the set_* methods, and delegate
Going about (finally) implementing my Infinity pmc, I noticed a lot of
redundant code in the Perl* classes. For instance, the polymorphic
behavior isn't implemented in PerlScalar, but rather in each of its
subclasses, which seems to rather defeat the purpose of making them
subclasses.
However, tr
