Re: [PHP4BETA] Re: convert_to_string_ex is not the solution.

From: Date: Fri, 17 Sep 1999 14:08:53 +0000
Subject: Re: [PHP4BETA] Re: convert_to_string_ex is not the solution.
References: 1  Groups: php.version4 
Request: Send a blank email to php-version4+get-4577@lists.php.net to get a copy of this message
On Fri, 17 Sep 1999, Zeev Suraski wrote: > On Fri, 17 Sep 1999, Thies C. Arntzen wrote: > > > zeev, > > > > i think i do agree (mostly;-) > > > > but how can i write a internal function that does not change the > > supplied parameters? if the scripter passes parameters via reference i > > should have a way to eg find out the string value for it without > > converting the users variable into a string! > > That may be true. First (at the risk of repeating myself once too many), > you must realize this isn't a getParametersEx() or a PHP 4.0 issue, but a > problem that's been around since the very first alpha of PHP 3.0. i know - the only reason i'm talking about this is that now we would have a chance to change things! if we're implementing the getParametersEx() in all modules we might as well get rid of this undocumented annoyance (my personal opinion). i don't think that anybody will get bitten if strlen(&$someint) won't convert $someint to a string in the future, do you? > > Now, there are two ways to go about this: > > 1. The newly introduced convert_to_*_ex() macros deliberately avoid > separating arguments that were passed by reference (to retain the > 'advertised' functionality). I could easily write macros (or add a flag > to the current macros) that causes them to separate the arguments > regardless of whether they are passed by reference or not. that would be nice - i would love to see a getParametersEx implementation of the implode function. (i also start to think that i had too much stress this week - my brain is smoking) > > 2. The above solution is not comprehensive - it doesn't give you any > tools to prevent the same thing from happening with legacy non-Ex code. we should be able to savely ignore that - see you own comment below (I don't recall a single) > comprehensive solution would be preventing the user from passing stuff by > reference to functions that advertise that they're not willing to take > stuff by reference. I haven't looked at the variable passing code for a > few months now, but it should be doable if we decide it's really > necessary. Whether it's necessary, though, is a big question. I don't > think people send arguments by reference just for the hell of it. i know a few people - including myself - who add a '&' here and there in my scripts to speed things up. and yes, i've got bitten by funtions that changed variable-types around without me expecting them to do so. > > We've had this behavior in PHP 3.0 for 1.5 years, and I don't recall a > single 'what the hell is going on' complaint about something of the sort > (and just about any PHP function modifies its arguments, and they all > happily take their arguments by reference if the user decides to do so). > > > > .... With PHP 4.0, the performance increase from passing by > > > reference is gone (since passing any type of argument is only a matter of > > > increasing reference count), but everything else still applies. > > > > as of now the performance increase is still there unless the internal > > function uses getParametersEx(). > > True. > > Zeev i just love to make thing better/faster/whatsoever - and in this special case i think the cost for that is not too high and "On the way". regards tc > > -- > ----------------------------------------------------- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > For a PGP public key, finger bourbon@netvision.net.il > > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany

« previous php.version4 (#4577) next »