Re: [PHP4BETA] Re: convert_to_string_ex is not the solution.
| From: | Thies C. Arntzen | 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