Assuming for the moment that we apply tye's two-stroke fix that makes the code work as intended, it still only works because of certain bit-related properties of the numbers in question (centering around the fact that 256 is a power of 2).

In this particular domain each number should be a single byte. The bit related property isn't arbitrary or coincidental - it's the very essence of the thing we're testing for. To me it's an obvious property that or-ing them together should result in a number less than 256. To others it may not be.

You can see why someone might view this as unintuitive.

Of course. It's a completely reasonably attitude. Just not a universal one.

To others, myself included, using a bitwise numerical or is a completely intuitive solution. Whether somebody find it obvious or not is going to be dependent on their experience.

I too would use Regexp::Common, but only because I loathe reinventing wheels. Are the regexpes that Regexp::Common::net uses internally any more or less "intuitive" that the other solutions offered? This, of course, depends on how familiar you are with Perl's regular expressions. It also depends on the domain you're playing with.

I still think the real problem is with the behaviour of the | operator in Perl. This is one of the very few places where the difference between a string containing a number and a number makes a real difference.

With all the other numerical operations numbers and strings containing numbers are treated the same way. It's only the bitwise operators that are treated differently. This, in my opinion, was a poor design choice and doesn't fit in with the way the rest of Perl is organised (eq vs ==, . vs +, etc.) I imagine this is one of the reasons the numerical and string bitwise operators are being separated out in Perl 6.

For example, the difference between the bitwise string and numerical operators has caught me out when I was manipulating preference values that were being represented as bit masks. Comparing different preferences sometimes worked and sometimes didn't, depending on whether preferences got injected into the system as strings or numbers. Since the injection of values happened a long way from the comparisons it took a heck of a long time to figure out what was going on.

(For those about to chime in and say bitmasks were a poor choice for preference values - I quite agree. We were manipulating values from a third party application.)

So, in conclusion, flyingmoose is not smoking crack (or, at least, if he is, you can't tell that from the node in question).

I never accused anybody of smoking crack.

Ignoring the reinventing the wheel issue, and just comparing the bitwise and comparison solutions, on some days I might even agree that the comparison solution was a better design choice.

However I do disagree that the original solution "does something that doesn't even make sense". It makes perfect sense - it's just that Perl in this particular instance does something that most developers wouldn't expect.

I still think the real problem is with the behaviour of the | operator in Perl. This is one of the very few places where the difference between a string containing a number and a number makes a real difference.

With all the other numerical operations

Whoah, hold on. Where on earth did you get the idea that bitwise operations are numerical operations? They're not. Bitwise operations operate in an arithmetic fashion, yes, but they operate on sequences of bits; what the arrangement of the bits represents is not a key feature of the bitwise operation, and it is not reasonable to assume that they necessarily represent numbers. Often (perhaps even usually) they represent characters, either in ASCII or unicode. Doing a bitwise operation in strings (especially XOR or a left or right shift, but sometimes and and or an or) is quite a common operation, one that we would *not* want to have randomly break if one of the strings happens to contain digit characters by some coincidence.

Sure, if you have separate bitwise operators for working on strings versus numbers, that would be fine. In Perl6, that will work out, no problem.

But you absolutely don't want to just make the bitwise operators that we have in Perl5 magically numerify their arguments. That would be exceedingly bad. That seems to be what the person who wrote the code expected to have happen; where he came up with such an absurd idea is quite beyond me. Like I said, it took me three readings to figure out why the author expected it to work. Why it didn't work was somewhat more obvious. Figuring out why the author expected it to work took more time, significantly more time, than subsequently figuring out why his expectations were broken.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Whoah, hold on. Where on earth did you get the idea that bitwise operations are numerical operations? They're not.

I meant numerical as in takes a number as an argument (123) as opposed to a string ("123"). I thought this was obvious from the context.

Doing a bitwise operation in strings (especially XOR or a left or right shift, but sometimes and and or an or) is quite a common operation, one that we would *not* want to have randomly break if one of the strings happens to contain digit characters by some coincidence.

Which is exactly my point :-) Random breakage is exactly what the current | operator's behaviour causes, just from the other side. Numerical bit based operations and string based bit operations are equally useful - but munging them together in one operator is asking for trouble in a language that transparently translates between numbers and strings in most contexts.

But you absolutely don't want to just make the bitwise operators that we have in Perl5 magically numerify their arguments.

I agree completely. I don't think I ever suggested it. However what we have now is just as bad since Perl programmers are used to strings containing numbers acting like numbers.