> Is the average Joe going to write parsers in the everydays work? Probably
not.
> But give him the power of goto and (s)he is going to shoot him/her in the
legs,
> in the heart, in the head. And even not only himself because (s)he will
create a
> legacy code which someone else has to understand and fix.
>
function foo() { foo(); }
for($i = 0; $i < 10; $i--);
`php -f {$_SERVER['PHP_SELF']}`;
while (!($fp = fopen('/does/not/exist', 'r')));All oversimplistic examples obviously, but the concepts aren't unfamiliar to those of us that actually volunteer in the trenches on usenet, irc, forums, etc... To quote Wez: "GOTO doesn't kill code, bad programmers do." > We have extract() > and we say in the docs it is not good to use it to populate variables but people > hack and workaround register_globals set to off by just using this function. > Taking away their tools will not make them code more intelligently, it'll send them off to another language where they CAN continue making the same mistakes. The way to breed better programmers is to point out their mistakes and suggest how they can correct them. But not every implementation of a particular concept is a mistake, if it were we'd have only one CMS, only one gallery script, only one Blog, and come to that.... only one language. > IMO PHP has enough power even without "goto". Left aside what Dijkstra has > written. goto code tends to become spaghetti one. > I could just as easily state that nested code with lots of OOP does the same thing. I'll say it agin: "GOTO doesn't kill code, bad programmers do." > Sometimes I miss it when > write PHP scripts (for example jumping between 2 clauses in a switch, something > which is used in var_dump() C implementation) but then I reconsider that it is better > this way. > Often it is better. And sometimes it's not. Funny how generalizations work. > Looks like I am -1 if that counts :) > Damn skippy it does. Everyone's oppinion counts. Whether the dicision is made to add it or leave it out, the voices of this community will have made an impact on that decision. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
