Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^3: Undocumented join() feature, now defunct? (++$i)

by tye (Sage)
on Oct 30, 2014 at 01:10 UTC ( [id://1105576]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Undocumented join() feature, now defunct? (optimization)
in thread Undocumented join() feature, now defunct?

The first argument to join is not code to be executed over and over again like with map and grep. So your example of join ++$i, @a doesn't actually pose a problem, unlike passing in a magical scalar that changes each time you look at it.

So, the behavior of your example code is already well defined.

- tye        

Replies are listed 'Best First'.
Re^4: Undocumented join() feature, now defunct? (++$i)
by tobyink (Canon) on Oct 30, 2014 at 08:10 UTC

    "The first argument to join is not code to be executed over and over again like with map and grep. "

    Agreed. But I think Loops' point is that nowhere in the documentation of join makes the above explicit.

    Given:

    my $str1 = $a . $x . $b . $x . $c; my $str2 = join $x, $a, $b, $c;

    You might assume they are equivalent. However, if $x is tied like in the example above, or is an overloaded object, they might not be. Given that johngg's code demonstrates that the behaviour of join in this regard has actually changed recently, it's not unreasonable to expect this behaviour to now be documented and ensured by the test suite.

      But I think Loops' point is that nowhere in the documentation of join makes the above explicit.

      Nice attempt at mind reading. Unfortunately, based on private messages that Loops and I exchanged, I believe you are wrong. But beyond guessing at one person's intent, I also disagree with your implied expectation.

      Show me anywhere in the Perl documentation where it makes it clear that a specific argument to a specific function is not magical like the first arguments to map/grep. Rather, the Perl documentation covers how expressions yield values and values are passed as arguments to functions. I really don't think it behooves the Perl documentation to repeatedly call out that "this particular argument to this particular function is ordinary and not magical like this other, rare case".

      Now we have to document that kill( signal(), @pids ) doesn't magically call signal() over and over to get a different signal for each PID? That chown( uid(), gid(), @files ) doesn't call uid() and gid() over and over again? That pack "I5", foo() doesn't magically call foo() 5 times?

      Does return need to document that sub foo { return bar() } $foo = foo(); print $foo, $foo; doesn't call bar() twice, potentially passing two different values to print? That split( sep(), $str ) doesn't get a fresh regex to match at each step?

      Given that johngg's code demonstrates that the behaviour of join in this regard has actually changed recently, it's not unreasonable to expect this behaviour to now be documented and ensured by the test suite.

      Yes, I believe it is unreasonable to bloat the documentation with such an explanation. To document that, you'd actually have to add to the join documentation, a summary of what a tied scalar even is and, really, some demonstration code. You'd end up with the explanation of this one optimization quirk constituting over 80% of the documentation of join(), obscuring the crux of what join() does to many readers. Or, if you add a much shorter explanation of this quirk, then you'll just have made the documentation potentially very confusing to many readers.

      The join documentation actually provides us with an example of specifically declaring what one argument isn't: 'Beware that unlike "split", "join" doesn't take a pattern as its first argument'. I think a much better version of that would not use the word "beware" as I don't see how this constitutes any type of trap. Unlike split(), join() doesn't take a regex pattern as its first argument because join() isn't matching (parts of) strings and so taking a regex pattern would simply make no sense. If you thought join() took a regex pattern, then you really didn't think about it very clearly. "Of course" belongs in that sentence more than "beware".

      At least that sentence is very short and so doesn't directly distract much. Though I think the documentation would be better without it (at least as worded). The word "pattern" is quite out of context in that short documentation. That sentence might be clear if one had just finished reading split before reading join. Otherwise, one could easily not be clear that "pattern" means "regex" and be worried about why this matters. It would be better if that sentence made it clear that you don't need to understand the split documentation to understand what join does, because that means understanding 14 times as much documentation!

      Adding tied variables and optimization quirks would be a much worse mistake.

      - tye        

Re^4: Undocumented join() feature, now defunct? (++$i)
by Loops (Curate) on Oct 30, 2014 at 03:12 UTC

    Yes, okay I see that. To expect otherwise would require the creation of a temporary every time you access a scalar more than once in your code. One implication of executable code being well defined as the first parameter to join, is that the following will fix johngg's code to work on old and new versions of Perl:

    <c>say join $inc+0, @arr;

    Where the creation of a temporary to hold the result is implied.

      I think you've pointed out a very cool way join() and tie() could have been used together had this been a known/documented behavior of join() from the beginning and one could even imagine join accepting a {} block or a sub reference to determine how $a and $b should be joined together.

      Unfortunately, there's no indication that this was intended to be possible and so the documentation should IMHO clearly point out exactly what the limitations of join() are, and that this behaviour is broken in certain versions.

      OR, they could unoptimize the code and make it official from some future version of Perl while pointing out clearly that although this behaviour can be seen in certain earlier versions it can't be relied upon until this exact version.

      After all, tie() is a part of Perl and it's not so unreasonable to try and use it to pull off magic tricks. That's what it's there for, like it or not.

      -- FloydATC

      Time flies when you don't know what you're doing

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1105576]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2024-03-28 09:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found