On Mon, May 15, 2006 at 03:29:23AM -0700, Leopold Toetsch via RT wrote: > Patrick R.Michaud (via RT) wrote: > > > I've run into the following problem using concat with > > Match objects from PGE. The code below performs a match, > > then attempts to concatenate a string with the results > > of the returned Match object: > > There are several problems with the internals of objects derived from > PMCs. The code tries to create a new destinaation according to the src > operands (this is where the failing clone is called).
Why does it try to create a new destination? I would expect this for n_concat, but not necessarily for concat. > If I turn that > part off, it still wouldn't work, as it calls get_string on the > contained Hash and not on the PGE::Match directly. This sounds wrong. Lots of subclasses are going to want to be able to override get_string and have Parrot do the right thing. Do similar problems exist for get_integer and get_number? > A workaround is to implement .sub __concatenate :multi(String, > PGE::Match) and use the n_concat opcode (which creates a new destination > result). Presumably this means we also need a .sub __concatenate :multi(PGE::Match, String) to handle the other order of arguments, yes? > > I'm also entering a todo test for the above into t/compilers/pge/02-match.t. > > I've adjusted this test, to use this workaround. I think the original test points out a bug that still needs fixing, but that's your call. Thanks, Pm
