On Tue, Nov 04, 2008 at 01:33:09PM -0600, Patrick R. Michaud wrote: : Consider the code: : : my $x = 3 | 'foo'; : my $y = $x.perl; : : : Does $y end up as a junction of strings or as a single string?
I think it may not actually matter much, if subsequent stringification of the junction produces a result with correct Perl syntax. : Asking more directly, does .perl autothread over a Junction? : If .perl does not autothread, then is there some way of knowing : which methods autothread and which do not? I think it would depend entirely on whether the Junction class defined method .perl, or relied on the authothreading implementation triggered by Object recognizing that it was handed a Junction. But it seems to me that if stringification of a junction returns a correct .perlish syntax, it's probably better to just let that happen lazily, on the assumption someone might want .perl to autothread for some reason, perhaps because .perl performs some kind of useful canonicalization prior to comparison. So I think the actual choice is driven by the fact that Str(Junction) is defined to work like you'd expect .perl to do if .perl did it, which it doesn't... : (The question of method autothreading over junctions came up at : the OSCON 2008 hackathon, but I don't know that it was ever : resolved. If it was and I've just forgotten or overlooked the : resolution, I'll be happy to have it pointed out to me.) Well, at the time we thought there might need to be some kind of VAR-like JUNCTION macro to give access to the Junction object, but if the decision is just based on whether Junction defines the method or not, that's not really necessary. And with this semantics, it's also no problem going the other way. If method .junk is defined in Junction, you can still force it to autothread by saying $junction.Object::junk(). Larry
