--- Piers Cawley <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> writes: > > > Togos <[EMAIL PROTECTED]> wrote: > > > >> $I1 = $I2 + $I3 > > > >> $P1 = $P2 + $P3 > > > >> Which, of course, doesn't work. But this is what > >> languages like Python or Ruby would expect to be > able > >> to do, as they don't need Perl's fancy variable > >> objects -- a register is good enough. > >> sementics of > > > > 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 > > But I'm not sure that's an enormous loss.
That would make a lot of sense (well, actually I think just using 'assign' would do the trick here). *I* like it, but then I'm not familiar with all the things that Dan and Leo are that would make it suck :) In any case, the way Dan described the way things are *supposed* to work (all PMCs act like variable references), it seems like there will be a need for an op that assigns the content of one PMC to another, so you could do like this: # foo = bar find_global $P1, "bar" find_or_create_global $P2, "foo" assign_content $P1, $P2 (plain ole' assign wouldn't quite do the trick, as it'd assign the reference to foo, and then foo'd be a reference to a reference, which probably isn't what you want). And, BTW, being subscribed only to the digest does seem to allow me to post to the list without delay. Whether that's a good thing or not is for y'all to decide :P __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
