Sorry, but your argument amounts to "we will never know how likely it is to get cancer from smoking because the vast amount of people aren't in our study, and there are more in people not in our study than are in it thus the data on how many people got cancer is totally useless".
Good thing you arent a doctor eh?
The fact is that if you check cpan and find out that 100% of the the modules on it use ~~ then its a pretty darn good suggestion this will break a lot of things. If you check it and find out that it doesnt occur even once then its pretty darn good suggestion it wont be found much in the wild. Personally were I pumpking I would feel a lot more at ease integrating a patch in the later case, but certainly wouldnt in the former.
Can we stop it with the "1 GB sample of code cant be used to establish usage frequencies" argument? Its a bit tired, and wasnt a good one in the first place anyway.
| [reply] |
Can we stop it with the "1 GB sample of code cant be used to establish usage frequencies" argument? Its a bit tired, and wasnt a good one in the first place anyway.
It's a very good sample of code, when you sample modules. That many Perl programs are programmed in an entirely different style, is a fact. These quick sysadmin scripts, screen scrapers, data processors, etcetera, you don't find on CPAN. CPAN is mostly modules, and many people have a very different programming style for those. And since CPAN is public code, I think it is sane to assume people pay more attention to their style when writing for CPAN than for "nobody else will ever read or have to maintain this".
On topic: there is no ~~ operator in Perl 5 yet. There is an ~ operator, and it can of course be stacked. The ~ operator does bitwise negation, and works on both numbers and strings, preserving the type. If you negate twice, you get the original input back. The side effects are interesting: it forces scalar context, and it stringifies things that aren't a number. Even though this is very interesting, this is a technique found mostly in golf and obfu. The readable, maintainable and documented way of forcing scalar context is the scalar operator. For stringification, "" . $foo and "$foo" are suggested and most commonly used. This is based on experience, not numbers.
~ is a unary prefix operator, the proposed ~~ is an infix operator. In practice, this means the only ambiguity you can get is when ~~ (without any whitespace in between the two operators) is abused to force scalar context for the first argument of a subroutine/function that is called without parentheses. The patch xmath made resolves this naturally resolves this to the old behaviour, breaking absolutely nothing. This is in agreement with the existing precedence table, which would get ~~ at the same level as the other equality tests. Ambiguity now only exists when there can be a term between the function's name and the first argument, without anything separating it from the first argument except maybe some whitespace. This is found in print $fh ~~localtime, but given that ~~ is obfuscation and a golf idiom, known by only Perl hackers, not found used in CPAN modules at all, my opinion is that it is safe to assume nothing will break. This time, it's based on actual research instead of "just" our combined experience.
Still, if despite all the unlikeliness, something still breaks, it can be fixed in at least three ways. The first being writing what you mean instead of abusing ~, meaning you change ~~ to either scalar or "".. The second solution is simply inserting whitespace or the unary noop operator + between the two tildes: ~ ~ or ~+~. The third is adding parens so that ~~ immediately follows (, which means it can no longer be interpreted as an infix operator.
| [reply] |