>>Just so we're clear, and to add a proper TODO test case, what would you >>consider the proper output to be? > > > I am opposed to such a change in behaviour.
Rest peacefully, so is Larry, I once cornered him on this :-) > <<= operates on numeric values, while vec operates on strings. > > vec($b,0,1) = 1 > > is just the same as > > $b = "\x0\x0\x0\x01" > > (ignoring endianess and int size complications) > > If the << and >> operators were to take any string as a bit pattern, then > it would break code like: > > $b="1"; $b <<= 2; print $b > > which should print 4, not "\xc4". But on the other hand Larry could see the argumentation my way too, that it should be possible to use <<= and >>= as bit shifters (looking at it from the C heritage it is strange that & | ~ ^ operate on strings as they were bitvectors, but the shift ops don't). So an unfortunate murky corner of the dual (strings and numbers), err, trefoil (strings and bitvectors and numbers), err, quatrefoil (byte strings and Unicode strings and bitvectors and numbers) nature of Perl strings. How to solve this, if this is to be solved? *I* see as an ugly asymmetry blemish, but since enraged hordes of people have not ascended upon yes over all these years, I think I am in a minority, and I can live with it. *IF* someone wants to fix this, maybe a pragma. Or maybe borgify Bit::Vector :-) -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
