Nick Glencross <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> I'd say that plain String PMCs don't have increment and decrement.
>>
>>It seems best to just remove scalar.increment and .decrement, which then
>>would automatically create the default_increment for Strings.
>>
> Sounds best, d
Leopold Toetsch wrote:
I'd say that plain String PMCs don't have increment and decrement.
It seems best to just remove scalar.increment and .decrement, which then
would automatically create the default_increment for Strings.
Sounds best, doesn't it? It's a bit 'perlish' to inc/dec a string
directl
Nick Glencross <[EMAIL PROTECTED]> wrote:
> On a semi-related note, there's some broken morph code in scalar. It has
> code like:
> void increment () {
> PMC_int_val(SELF) = DYNSELF.get_integer() + 1;
> }
> which is then used by subclasses String, Integer and Float.
Integer and
Leopold Toetsch wrote:
Nicholas Clark <[EMAIL PROTECTED]> wrote:
I'm trying to understand how morph works. perlscalar's morph looks like this:
[ broken code ]
On a semi-related note, there's some broken morph code in scalar. It has
code like:
void increment () {
PMC_int_val(SELF
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I'm trying to understand how morph works. perlscalar's morph looks like this:
[ broken code ]
> I think that there are 2 bugs here
At least, yes. The better and general morph code is pmc.c:pmc_reuse().
> 2: The code isn't thread safe, even though it t
On Tue, 12 Apr 2005, Nicholas Clark wrote:
I think that there are 2 bugs here
1: Morphing from enum_class_PerlString to enum_class_BigInt or
enum_class_Complex looks broken. The return in the second if clause will
quit the function and the DYNSELF.init() will never get called.
Can anyone easily wri
