On Tue, 2009-01-13 at 22:12 +0100, Jochem Maas wrote:
> Robert Cummings schreef:
> > On Tue, 2009-01-13 at 15:50 +0100, Jochem Maas wrote:
> >> Ashley Sheridan schreef:
> >>> On Mon, 2009-01-12 at 15:15 -0500, Frank Stanovcak wrote:
> >>>> I've googled, and found some confusing answers.
> >>>> I've tried searching the history of the news group, and only found info
> >>>> on
> >>>> switch or elseif seperately. :(
> >>>>
> >>>> Strictly from a performance stand point, not preference or anything
> >>>> else, is
> >>>> there a benefit of one over the other?
> >>>>
> >>>>
> >>>> for($i=0;$i<3;$i++){
> >>>> switch($i){
> >>>> case 0:
> >>>> header pg1 code
> >>>> break;
> >>>> case 1:
> >>>> header pg2 code
> >>>> break;
> >>>> case 3:
> >>>> header pg3 code
> >>>> break;
> >>>> };
> >>>> };
> >>>>
> >>>>
> >>>> or would that be better served using an if...elseif structure?
> >>>>
> >>>> Frank
> >>>>
> >>>>
> >>>>
> >>> And a switch is a lot neater for dealing with these sorts of things. I
> >>> tend never to use if...elseif's at all, and use switches. Like Rob said,
> >>> you can fall into further cases below, and it's very simple to add more
> >>> at a later date. There is one place where an if...elseif would work and
> >>> a switch could not, and that is where you were performing lots of
> >>> different logic tests on different variables.
> >> switch (true) {
> >> case ($x === $y):
> >> // something
> >> break;
> >>
> >> case ($a != $b):
> >> // something
> >> break;
> >>
> >> case (myFunc()):
> >> // something
> >> break;
> >>
> >> case ($my->getChild()->hasEatenBeans()):
> >> // something
> >> break;
> >> }
> >>
> >> evil ... but it works.
> >
> > What is your intent if both $x === $y and $a != $b? From the above
> > example only the code for $x === y will execute.
>
> no shit. that would be the intention too :-)
>
> > This is hideous from a
> > readability point of view since the first case and second case are
> > matches, but only the first will get executed. This is better
> > represented using an if/elseif/else structure to indicate the exclusion
> > of later expressions.
>
> that is just a matter of opinion. it's no different to an
> if/elseif/elseif/elseif
> block functionally ... you just don't like the way it looks
No, it's not just a matter of functionality in this case. It malforms
the semantic meaning of the named expressions so that they no longer
provide clearly readable meaning.
> ... I'd point out though that you had no trouble determining the
> code's intention correctly, and I'm sure you didn't stare at it too
> long
I'm special though ;)
> ... so I'd hazard to say it's not *that* illegible.
Yes, that's right, it's a hazard alright. A hazard to avoid by any
self-respecting developer who's not competing in a code obfuscation
contest :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php