|
Re^3: More intelligent warning?
by Corion (Patriarch) on Feb 05, 2010 at 15:02 UTC
|
I guess it's too late for 5.12, but for 5.14, I consider it fair game. And yes, I really dislike this side effect, even though it might come in very handy while golfing or for obfuscation...
| [reply] |
Re^3: More intelligent warning?
by LanX (Saint) on Feb 05, 2010 at 15:53 UTC
|
Hm That's a real "WTF were they thinking" moment :)
Most of Perl's oddities you can squint your eyes a bit and see how and why they came about. And often, how useful they can be.
Indeed!
... wouldn't it be nice to have a no oddity pragma to deactivate all these rarely needed special features?
| [reply]
[d/l] |
|
|
Hm. Interesting idea. What else would you include?
How about disabling the use of @ARGV as the implicit target of push, pop, shift, unshift (other?) outside of a sub?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
|
|
|
|
|
e.g. for the flip-flop operator literal numbers mean line numbers, that hinders using flip-flop for other purposes than parsing files.
UPDATE: And IMHO the scalar comma operator produces more unwanted results than benefits.
In general, I think the features dropped in Perl6 are a good starting point for more ideas.
| [reply] |
Re^3: More intelligent warning?
by JavaFan (Canon) on Feb 05, 2010 at 16:06 UTC
|
But "I know you asked me for the count of tokens, but by the way, I've also stuck those tokens into @_ (silently overwriting your sub args!) just in case that's useful."? Nope! I can not see any rational for that.
You're assuming split was written to easily count the number of tokens. It wasn't. It was written to split a string. Which it does. Even in void and scalar context. The fact it returns the number of tokens in scalar context is the additional feature, not its reason for existence.
I guess the reasoning was "Hmmm, we have a function that splits a string into other strings. What can we do if there are users who call this in non-list context?" Not throwing away the result and putting in in the default list topicalizer doesn't seem that far fetched to me.
| [reply] |
|
|
You're assuming split was written to easily count the number of tokens.
Um. Nope. I made no such assumption. Thats purely your assumption.
I agree part way. I can see the thought train that leads to some of it. I've written this function that splits strings. It can be called in 3 contexts. What is the logical thing to do in those contexts?
- List context: return the list of bits.
- Scalar context: Return how many bits.
- Void context: He's asked us to split, but wants nothing back. I guess we could stick the bits in @_ and let him access them there.
But, I fail to see a good (nor even a bad) use case for returning the count AND sticking the bits in @_.
Maybe there's one, but I just don't see it. If it stuck them in @F per -a, maybe.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Re^3: More intelligent warning?
by shmem (Chancellor) on Feb 07, 2010 at 18:43 UTC
|
Nope! I can not see any rational for that.
Hmm, well. $_ is the default "this", so @_ is the default "these". If split is called implicitly on $_, it seems somewhat logical to me to implicitly split into @_.
Bu then, the following arguably should not implicitly split into @_ :
perl -wle '$n="";$f="abc";$n=split//,$f;print for @_'
To defeat that behavior we have to use the "operator" with the disputed name...
perl -wle '$n=""; $f="abc"; $n=()=split//,$f; print for @_'
update:
That looks like coming from looong ago. Consider:
while(<>) {
$n = split;
warn "processing $n tokens\n";
&process; # implicitly takes @_
}
So... another reminiscence of perl4. perl4! | [reply]
[d/l]
[select] |
|
|
I don't have a problem with the implicit split to @_, when called in a void context. It wouldn't do anything useful at all otherwise.
And the number of items produced is then readily availble as scalar @_:
while(<>) {
split;
warn "processing " . @_ . " tokens\n";
&process; # implicitly takes @_
}
Having split in a scalar context just return the count also makes sense. (To me at least.)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |