Piers Cawley <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> That and other arguments are of course all correct. I just have the gut >> feeling that having both opcode and vtable variants blows core size up >> to an isane value. > Couldn't you have a single opcode, C<assign_content Pn, Pm>, which uses > Pn's vtable assignment, and make C<add $P1, $P2, $P3> etc simply use > the 'make a new PMC' thing. That means that, to get the current > semantics you'd have to do > $P2 = $P3 + $P4 > assign_content $P1, $P2 When C<add> and friends create a new PMC always, this isn't really good, when working with any kind of references: $P2 = global "$a" $P2 = $P3 + $P4 Globals and lexicals already have a PMC inside, which we should just assign a new value. Aggregates are a bit different, they might or might not have already a value: $P2 = hash["key"] $P2 = $P3 + $P4 BTW - it's still undecided, if the created PerlUndef for a non-existent key should be stored in the hash. The automatic creation of LHS PMCs is really only usefull with temps. But if such a temp isn't stored into an array or such, the temp PMC could even be reused, e.g. if the temp is the RHS of another math operation. leo
