Re: Unsigned Problems Revisited

Before I respond, I just though I would give a summary of how other languages solve this problem. ------------------------------------------------------------------------- Perl: Always performs logical unsigned shift, unless "use integer" is in effect Java: >>>, >>>= (they do not have <<<. or <<<=) C#: Has Signed and Unsigned types Ruby: Always performs logical unsigned shift, but offers Operator Overloading, which allows an object to be implemented to perform arithmetic shifting Python: Must use long ints (which is bignum) On Wed, 2002-10-23 at 02:20, Kristian Koehntopp wrote: > On Tuesday 22 October 2002 19:23, Jason T. Greene wrote: > > If for some reason we HAVE to have a symmetrical bogus unsigned left > > shift operator, and we completely disagree with my arguments on > > overloading the HEREDOC operator, then we can implement >>>>, > > >>>>=, > > <<<<. <<<<= as the unsigned shift operators. > > There is no need for operators to be composed from nonalphabetic > characters. You could use a function (shift is already taken, but > ashift and ushift for arithmetic shift and unsigned shift are free > and value, direction and shift width are parameters). Or you could use an > operator with a name similar to assembler instructions > (asl, asr for arithmetic shift left and right, lsl and lsr for logical > shift left and right). I rather prefer this to an arbitrary number of > angle brackets. There are 2 problems with using alphanumeric characters: 1. Would require whitespace between identifiers (Fine with me). 2. Assign behavior: would it be lsr= lsl=? or lsra, lsra? Stig and I had a discussion in irc a few months ago about adding a 'u' to the operators. It's simple, but looks unique i.e. u<<, u>>, u<<=, u>>= > > 2. Shift behavior declare compiler directive > > -------------------------------------------- > > > > Implement a declare compiler directive which will change the behavior of > > Sucks. > Ok that is your opinion, could you elaborate why this 'sucks'? > > 3. Implement Unsigned Data types > > --------------------------------- > > This would be a very good idea, but is hard to do in the current > typing concept of PHP. > I was not referring to adding static typing. It basically boils down to being able to execute the statement : $b = (uint) 1 << 2; The only problem with it is that just like any type in php, it can easily change. > > (Shift function) > > See above, if function, then as generic as possible. > > Kristian >