in reply to Re^2: Overloading Weirdness
in thread Overloading Weirdness

The bottom line is that it is an old legacy app and we need the delayed decision.

Ok, well the best suggestion I can come up with at the moment is to not overload stringification and make that an explicit method call. That would allow you to weed out those cases where the objects are stringified when you don't want them to be.

Replies are listed 'Best First'.
Re^4: Overloading Weirdness
by pudge (Sexton) on Jun 23, 2018 at 19:16 UTC
    Thanks, but can't do it that way. The whole point is that we cannot redo all of the many places where we compile strings.
      it is an old legacy app ... we cannot redo all of the many places where we compile strings.

      I understand your point - to a degree. What I've got so far is you've got a large codebase where HTML is stitched together via "<html>$str</html>" and the like, and you've discovered that $str sometimes needs to be encoded, and you can't decide whether or not until output (for reasons you haven't explained yet, but ok).

      But like you showed in the root node, you're going to have to make changes to that code base: 1. you're going to have to change all the places where variables like $str are created (my $str = str::new('<encode this later>');), and 2. you're going to have to change the output code at some places (print $html->encode;).

      So what I'm guessing is that the code you don't want to change is all the code like "<html>$str</html>", probably because there is lots of code like that.

      But you sometimes have code like the "bad" cases in the root node. You haven't told us how many cases in your code base there are like this, but if it's not too many, perhaps you could weed them out with a warning, like this:

      Another idea might be to inspect the optree of your source code to find stringifications that haven't been optimized away:

      $ perl -MO=Concise,-src | perl -ne \ '/^#\s+\d+\s*:/&&($a=$_);/(?<!ex-)stringify/&&print$a,$_' syntax OK # 34: my $zz; $zz = "$x $y"; # warns 1a <@> stringify[$zz:257,258] sK/TARGMY,1 ->1b

      Although that feels kind of hackish, and I don't have enough experience with B::Concise to say if there are any big downsides.

      I could get into the Why ... but it's a long and boring story.

      Telling us the background might prompt some other ideas for other solutions :-)