Re: [PHP] The goto discussion on the Internals List
On Thu, June 9, 2005 6:49 am, Jochem Maas said: Richard Lynch wrote: And, for the record, *I* sure as hell don't want to see a GoTo in PHP. whats your take on ifsetor()?, personally I would like to see it. I think its a great way to teach newbies about checking vars before use (if nothing else) This probably doesn't belong on this list, but I was asked here, so I'll answer here. [Plus I'm not on the internals list.] Re-direct followups off-list or back to -internals or ... I don't think ifsetor is going to encourage newbies to check variables before use. In fact, I think it's just going to confuse newbies with one more extra way to do the same thing. Only turning E_ALL on by default (which I asked for in PHP 4.0 and PHP 5.0 and will ask again for PHP 6.0 and 7.0 and 8.0 ...) will actually educate newbies that they are doing something fundamentaly wrong in their Programming to use variables they haven't initialized. Spare the rod, spoil the child. Spare the E_NOTICE, spoil the newbie. There's currently NOTHING other than 10,000 pages of docs to tell a newbie they NEED to check vars. The quickie examples everybody rattles off don't check vars. The MANUAL doesn't even consistently use good programming practices in its examples -- though it gets better over time, mostly. Then people want to simplify the examples down to just the function/feature in question, and we go back to Bad Code. ifsetor doesn't really seem to add much value to me. $foo $: $default; $foo = ifsetor($default); $foo = isset($foo) ? $foo : $default; What? 15 to 20 characters, depending on the ifsetor syntax? I'll pass. I don't think ifsetor adds enough value to the language to be worth the confusion of having a second way to do the same thing in ~20 more characters, personally. [shrug] If it gets added, I'll probably never even bother to use it. I've been typing the isset() ? : construct for so many years, that I'm not gonna switch for the sake of a few less keystrokes. Sorry. I certainly don't want to be the one answering the 10,000 emails to this list: Which is better? isset() ? : or ifsetor? Which one is faster? Why are there two ways to do this? What's this ifsetor thing? / What's this isset() ? : thing? And then the arguments between the experts (self included) over which one is better and why. Cuz I'll tell you right here, right now, that's one consequence of this proposed change. 10,000 more emails to php-general in the next year or two, just about 'ifsetor'. My vote, if anybody cares to count it: -1 -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
Richard Lynch wrote: On Tue, June 7, 2005 10:59 am, Robert Cummings said: PHP has never purported to be an OOP only language. It advocates both procedural and OOP programming methodologies. Just ask Richard Lynch :) Don't bother asking me - Ask Rasmus :-) And, for the record, *I* sure as hell don't want to see a GoTo in PHP. whats your take on ifsetor()?, personally I would like to see it. I think its a great way to teach newbies about checking vars before use (if nothing else) If you're down to the clock cycles where GoTo versus if/else matters, you should be coding that part in C anyway. [He says blithely, not having coded in C in over a decade.] PS I never knew PHP and I shared our birthday! Two reasons to celebrate!!! hope you had a good one! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
On 6/9/05, Jochem Maas [EMAIL PROTECTED] wrote: whats your take on ifsetor()?, personally I would like to see it. I think its a great way to teach newbies about checking vars before use (if nothing else) That and error_reporting( E_ALL ); -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
On Thursday 09 June 2005 23:08, Greg Donald wrote:
On 6/9/05, Jochem Maas [EMAIL PROTECTED] wrote:
whats your take on ifsetor()?, personally I would like to see it. I
think its a great way to teach newbies about checking vars before use
(if nothing else)
That and error_reporting( E_ALL );
and
ini_set('display_errors', TRUE);
So they don't have to figure out where the error log is (yet).
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
New Year Resolution: Ignore top posted posts
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] The goto discussion on the Internals List
On Tue, June 7, 2005 10:59 am, Robert Cummings said: PHP has never purported to be an OOP only language. It advocates both procedural and OOP programming methodologies. Just ask Richard Lynch :) Don't bother asking me - Ask Rasmus :-) And, for the record, *I* sure as hell don't want to see a GoTo in PHP. If you're down to the clock cycles where GoTo versus if/else matters, you should be coding that part in C anyway. [He says blithely, not having coded in C in over a decade.] PS I never knew PHP and I shared our birthday! Two reasons to celebrate!!! -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
I agree 100% with Greg's comments for the goto() / ifsetor() discussion on the internals list. As far as speed goes if the dev team knew of ways to improve specific parts of the codebase (while maintaining the rest of the features available in PHP) then I'm confident they would make that change. There was one comment on the internals list that perhaps the documentation should have a big fat red warning label that says DO NOT USE THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING. I guess the developers assume users actually read the manual, but I think this list has proved time and again that end users don't do this. ;) This is especially true for newbies (i.e. the ones most likely to get burned by using goto() all over their code). PHP-dev team: at the moment you are supplying me with 95% of the features that I need with a base installation. Just focus on getting Unicode support, make it stable, and make it fast. -- Teach a man to fish... NEW? | http://www.catb.org/~esr/faqs/smart-questions.html STFA | http://marc.theaimsgroup.com/?l=php-generalw=2 STFM | http://php.net/manual/en/index.php STFW | http://www.google.com/search?q=php LAZY | http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
Jason Barnett wrote: I agree 100% with Greg's comments for the goto() / ifsetor() discussion on the internals list. As far as speed goes if the dev team knew of ways to improve specific parts of the codebase (while maintaining the rest of the features available in PHP) then I'm confident they would make that change. There was one comment on the internals list that perhaps the documentation should have a big fat red warning label that says DO NOT USE THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING. I guess the developers assume users actually read the manual, but I think this list has proved time and again that end users don't do this. ;) This is especially true for newbies (i.e. the ones most likely to get burned by using goto() all over their code). PHP-dev team: at the moment you are supplying me with 95% of the features that I need with a base installation. Just focus on getting Unicode support, make it stable, and make it fast. and fix whatever it is that causes failed require_once statement to segfault ( there are other instances where simple syntax errors causes segfaults - the really annoying thing is that I/you get no logs, no errors, nothing - not very easy to debug) ... this has been true since php5 beta funny thing is I only see it happening in very complex scripts, which means its obviously not a real bug because I can't create a short reproduce script - (slight dig at someone there) both goto and ifsetor (and a whole host of other stuff like PDO) I can miss, whereas proper unicode support, better datetime handling and more indepth/usuable documentation on php5 are things I am really looking forward to... like rather than giving us even more features why not give us some good/complex examples of the newer features (SPL, Exceptions, etc, etc) and give us the knowledge we need to leverage the tools we already have. heh Jason, your sig will require a new item ;-): NEW? | http://www.catb.org/~esr/faqs/smart-questions.html STFA | http://marc.theaimsgroup.com/?l=php-generalw=2 STFM | http://php.net/manual/en/index.php STFW | http://www.google.com/search?q=php LAZY | http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins GOTO | heh noob don't use 'goto'. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
If there is a use for goto, that can cause certain tasks to be acomplished faster using goto, and that implementing goto in the ZE isn't too much work, then I don't see a problem with implementing it. I'm not totally sure why, but Zend used goto, in the Zend Engine(one used for php4) code for looping through opcodes. I'm sure zend saw some benefit in using goto's when they decided to use them in the ZE Backend. Goto has (I believe) been described as a method of shooting yourself in both feet at the same time. Maybe if there was an enable_expert_mode() command to enable expert mode for that page, or maybe a ?php_expert opening brace, that enable functionalty that is recommended for use only by experts. - Just a thought. On 6/7/05, Jason Barnett [EMAIL PROTECTED] wrote: I agree 100% with Greg's comments for the goto() / ifsetor() discussion on the internals list. As far as speed goes if the dev team knew of ways to improve specific parts of the codebase (while maintaining the rest of the features available in PHP) then I'm confident they would make that change. There was one comment on the internals list that perhaps the documentation should have a big fat red warning label that says DO NOT USE THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING. I guess the developers assume users actually read the manual, but I think this list has proved time and again that end users don't do this. ;) This is especially true for newbies (i.e. the ones most likely to get burned by using goto() all over their code). PHP-dev team: at the moment you are supplying me with 95% of the features that I need with a base installation. Just focus on getting Unicode support, make it stable, and make it fast. -- Teach a man to fish... NEW? | http://www.catb.org/~esr/faqs/smart-questions.html STFA | http://marc.theaimsgroup.com/?l=php-generalw=2 STFM | http://php.net/manual/en/index.php STFW | http://www.google.com/search?q=php LAZY | http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] The goto discussion on the Internals List
[snip]
Goto has (I believe) been described as a method of shooting yourself
in both feet at the same time.
[/snip]
goto (not a 'new' construct as was mentioned earlier) had its uses, but
thos would seem depricated now as you can call a function, which is
essentially what a goto did. Consider;
if('foo' == $bar){
goto(1001); //essentially a line number (remember, old school)
OR goto(LABEL); //defined constant
} else {
goto(2001);
}
VS.
if('foo' == $bar){
assimilate($bar);
} else {
anhylate($bar);
}
Where problems arose from goto they would arise from function use as
well. Nesting goto's was every bit as challenging as properly
constructing regex statements. goto also did not fit as well with OOP
methodology, being more of a procedural construct in accordance with the
procedural programming at the time that it was conceived.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] The goto discussion on the Internals List
On Tue, 2005-06-07 at 10:50, Jay Blanchard wrote:
[snip]
Goto has (I believe) been described as a method of shooting yourself
in both feet at the same time.
[/snip]
goto (not a 'new' construct as was mentioned earlier) had its uses, but
thos would seem depricated now as you can call a function, which is
essentially what a goto did. Consider;
if('foo' == $bar){
goto(1001); //essentially a line number (remember, old school)
OR goto(LABEL); //defined constant
} else {
goto(2001);
}
Absolutely nobody in this day and age advocated goto lineNumber. The
only use to have useful advantage is goto labelName and of course
that is where the labelName exists within the current execution scope.
A function call is not an acceptable replacement since you incure the
overhead of setting up the function and the stack. Contrast the
difference in speed between is_null( $foo ) and $foo === null.
VS.
if('foo' == $bar){
assimilate($bar);
} else {
anhylate($bar);
}
Where problems arose from goto they would arise from function use as
well. Nesting goto's was every bit as challenging as properly
constructing regex statements. goto also did not fit as well with OOP
methodology, being more of a procedural construct in accordance with the
procedural programming at the time that it was conceived.
PHP has never purported to be an OOP only language. It advocates both
procedural and OOP programming methodologies. Just ask Richard Lynch :)
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] The goto discussion on the Internals List
[snip] Absolutely nobody in this day and age advocated goto lineNumber. The only use to have useful advantage is goto labelName and of course that is where the labelName exists within the current execution scope. A function call is not an acceptable replacement since you incure the overhead of setting up the function and the stack. Contrast the difference in speed between is_null( $foo ) and $foo === null. [/snip] The speed difference is negligible though, in this day and age, dependent upon how much hair-splitting you would care to do. You're still setting aside a block of code which will have to be parsed and you incur the same setup if the goto section is the same code as the function. The overhead is introduced in the calling of the function. But we're splitting hairs here :) [snip] PHP has never purported to be an OOP only language. It advocates both procedural and OOP programming methodologies. Just ask Richard Lynch :) [/snip] I never said that PHP was OOP only, I was just pointing out how, historically, the goto was depricated. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
Jay Blanchard wrote: snip The speed difference is negligible though, in this day and age, dependent upon how much hair-splitting you would care to do. You're still setting aside a block of code which will have to be parsed and you incur the same setup if the goto section is the same code as the function. The overhead is introduced in the calling of the function. But we're splitting hairs here :) /snip Ah, but goto isn't really the same as a function. Functions are along the lines of gosub. *not to be left out on the splitting of hairs ;) -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
On Tue, 2005-06-07 at 14:26, John Nichel wrote: Jay Blanchard wrote: snip The speed difference is negligible though, in this day and age, dependent upon how much hair-splitting you would care to do. You're still setting aside a block of code which will have to be parsed and you incur the same setup if the goto section is the same code as the function. The overhead is introduced in the calling of the function. But we're splitting hairs here :) /snip Ah, but goto isn't really the same as a function. Functions are along the lines of gosub. *not to be left out on the splitting of hairs ;) A more realistic speed hit is the fact that using if/elseif/else or switch statements requires on average an O( n ) lookup, whereas a proper goto implemention is O( 1 ). Now I'll give you you could do an label to function map and use that instead, but that's still O( lg n ). Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] The goto discussion on the Internals List
[snip] A more realistic speed hit is the fact that using if/elseif/else or switch statements requires on average an O( n ) lookup, whereas a proper goto implemention is O( 1 ). Now I'll give you you could do an label to function map and use that instead, but that's still O( lg n ). [/snip] Ah the good old days, when calculating clock cycles was done more than punching cards. (Fortran flashback!) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] The goto discussion on the Internals List
I perused the discussion about the inclusion of goto into the PHP language on the php.internals list. From a PHP end-user's perspective, I would suggest that rather than focusing on adding new language constructs such as goto, that the development team put 100% focus on making what it already has as fast and stable as possible (and maybe iron out the Unicode issue) so that the corporate and hosting community will more readily accept it. I've been begging my hosting company to upgrade to 5.0.x for months but they say we're going to wait until next year when it has stabilized. That's really frustrating because I find 5.x's current features so compelling and useful. Thanks, C Drozdowski -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The goto discussion on the Internals List
On 6/6/05, Chris Drozdowski [EMAIL PROTECTED] wrote: I perused the discussion about the inclusion of goto into the PHP language on the php.internals list. Yeah, I've been following it as well.. seems there would be bigger fish to fry, I dunno. I benched Ruby and PHP doing some simple random number addition recently and PHP is pretty slow in comparison. If the simple stuff is slow I imagine the complex stuff is pretty slow as well. Not bashing PHP at all, but I wouldn't call it 'fast' either. I doubt many people would use goto anyway. I have nothing against it technically or personally, but over the years it's been burned into my brain that using it is _bad_. *shrug* I suspect I might use it if it were there. I do think I'd make heavy use of ifsetor(), I would gladly use that instead of $i = isset( $_GET[ 'i' ] ) ? $_GET[ 'i' ] : 0; From a PHP end-user's perspective, I would suggest that rather than focusing on adding new language constructs such as goto, that the development team put 100% focus on making what it already has as fast and stable as possible (and maybe iron out the Unicode issue) so that the corporate and hosting community will more readily accept it. I hear ya on that. I think it might be similar to the Apache 2 thing. We already got PHP4 which works pretty well so why risk it. PHP5 runs great for me, but I see their point of view. I've been begging my hosting company to upgrade to 5.0.x for months but they say we're going to wait until next year when it has stabilized. The guys at http://www.ocssolutions.com gave me PHP 5.04, MySQL 4.1, and Ruby on Rails this weekend. They will build a box to your spec, even for a shared account. I'm not affiliated with them in any way, found them using Google. That's really frustrating because I find 5.x's current features so compelling and useful. I find a great many of the new 5.0 features get emulated using PHP4 code in the user comments in the manual. -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
