pmc_i_ops branch.

[Patrick R. Michaud]

On Mon, Jun 08, 2009 at 10:07:06AM +1000, Vasily Chekalkin wrote:
> Few days ago I created branch for implementing mathematical ops in term  
> of i_ops. E.g. "c = add a, b" implemented as "c = a; c+= b". No test  
> failures (actually I fixed some i_ops which was wrong before. E.g.  
> Integer.i_add(Complex) and so on), so I'm going to merge this branch to  
> trunk.
>
> Any objections?

I object, somewhat strongly.

If I'm reading the branch diff correctly, it appears to be
replacing most instances of

       dest = pmc_new(INTERP, VTABLE_type(INTERP, SELF));

with

       dest = SELF.clone();

However, these are not exactly the same thing.  In particular,
I can imagine that a VTABLE_clone operation for some (derived)
PMC types could be a lot more expensive than simply creating
a new empty instance, which is what happens now.

In short, the branch changes the semantic of the math opcodes
from being "add these two things together, producing a third"
to "clone one thing and inplace add something else to that".
I'd find that a bit surprising, especially when my 
custom VTABLE_clone starts getting called for simple math 
operations.

This is not purely hypothetical -- Rakudo does define a
custom VTABLE_clone that gets inherited by most of its types.
Having the mathematical opcodes start to invoke that clone 
operation is likely to significantly impact things in Rakudo
(and not in positive ways).

So, I'm against this change -- I think the mathematical 
operations should _not_ be using clone.

If I end up being out-voted on this one, then I think
the change should at least go through a deprecation cycle,
since it represents a real behavioral difference from what
was present in 1.0.

Pm