Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:04 PM +0200 4/19/04, Leopold Toetsch wrote:
>>
>>I'm not sure if we need the two different get vtable methods though. At
>>least there isn't any usage for these ;)
> Well, think of aggregates (where it's most likely to be used)
That was the next ques
ssed in PMC. (the
get_[string|pmc] vtable methods have a similar issue--should they
return the real thing or a copy?)
assign Px, Sy $1->vtable->assign_string_native # copy string
setPx, Sy $1->vtable->set_string_native # refer to string
assign Px, Py $1->vtable-
t_[string|pmc] vtable methods have a similar issue--should they
> return the real thing or a copy?)
assign Px, Sy $1->vtable->assign_string_native # copy string
setPx, Sy $1->vtable->set_string_native # refer to string
assign Px, Py $1->vtable->assign_pmc
set
At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
This vtable currently copies the string.
Yeah, and we've the same issue with set_pmc -- some of the versions
make a copy and some just use the passed in PMC. (the
get_[string|pmc] vtable methods have a similar issue--should they
return the real th
This vtable currently copies the string. I've tried now:
PMC_str_val(SELF) = value;
instead (perlstring.pmc:193). This breaks exactly one test which
explicitely tests this behavior nothing else.
And there is of course the assign opcode, that does the same. But we
could have:
set P0, "xx"
