Re: Re: A really wacky design decision

From: Date: Sat, 03 Oct 2009 13:47:21 +0000
Subject: Re: Re: A really wacky design decision
References: 1 2  Groups: php.general 
Request: Send a blank email to php-general+get-298513@lists.php.net to get a copy of this message
On Sat, 2009-10-03 at 15:33 +0200, Ralph Deffke wrote: > u increment after! asigning, so far so good, but for math reasons the > interpreter has to keep in mind the 123 you want to assign before increment > to the same var. > > this is absolutely correct what php does here. > > $num = ++$num; would print 124 > the same like > $num++; > > on the other hand this is just bullshit I would release any programmer using > that type of code. > > ralph_deffke@yahoo.de > > <clancy_1@cybec.com.au> wrote in message > news:8fudc5tc6qvfj4n297kvjlqd3s7sjdkvqb@4ax.com... > > Daevid Vincent is surprised that: > > > > $num = 123; > > $num = $num++; > > print $num; //this prints 123 and not 124 ?!! > > > > To me this is relatively logical. As I understand it, the post-increment > operator says "do > > something with the variable, and then increment it. The trouble in this > case is that we > > are doing something irrational; we are copying the number back to itself, > and to me it is > > reasonably logical (or at least no less illogical than the alternative) to > assume that if > > we copy it to itself, then increment the original version, the copy will > not be > > incremented. > > > > However there is one feature of PHP which, to my mind, is really bad > design. How many of > > you can see anything wrong with the following procedure to search a list > of names for a > > particular name? > > > > $i = 0; $j = count ($names); while ($i < $j) > > { if ($names[$i] == $target) { break; } > > ++$i; > > } > > > > As long as the names are conventional names, this procedure is probably > safe to use. > > However if you allow the names to be general alphanumeric strings, it is > not reliable. One > > of my programs recently broke down in one particular case, and when I > eventually isolated > > the bug I discovered that it was matching '2260' to '226E1'. (The > > logic of > this is: 226E1 > > = 226*10^1 = 2260). > > > > I agree that I was well aware of this trap, and that I should not have > used a simple > > comparison, but it seems to me to be a bizarre design decision to assume > that anything > > which can be converted to an integer, using any of the available > notations, is in fact an > > integer, rather than making the default to simply treat it as a string. It > is also a trap > > that it is very easy to fall into if you start off thinking about simple > names, and then > > extend (or borrow) the procedure to use more general strings. > > > > And can anyone tell me whether, in the above case, it is sufficient to > write simply: > > if ((string) $names[$i] == $target), > > > > or should I write: > > if ((string) $names[$i] == (string) $target)? > > > > (I decided to play safe and use strcmp ().) > > > > > You'd release a programmer for using the incremental operators for self assignation? Thanks, Ash http://www.ashleysheridan.co.uk

« previous php.general (#298513) next »