Steph Fox wrote:

>  The more I look into this, the weirder it seems.
>  
 >  [snip]
 > 
>  There's nothing wrong with it?
>  So why throw an error at all?

>  I have to say, I'm really confused over this. Either it's wrong, so you 
>  deliver a warning, or it's OK, so you don't. But what *really* bothers 
>  me is that the community seems to be under the impression that the rules 
>  changed with PHP 5, which is absolutely untrue. This threw an E_NOTICE 
>  under PHP 4.0 which has been shifted, first to E_STRICT (I haven't 
>  checked this) and then to E_DEPRECATED in 5.3.

+1,  I agree.   But I can only speak for 5.x since this is where the 
platform we decided to begin with PHP extension support.

I didn't see the reason for it, but I also thought that it was to 
aggressive too.  Meaning, I can see it applied to explicit PHP code, but 
not extensions.  I can also see it as a LINT concept at the PHP code 
level which is one of the areas one might fall into bugs, i.e, not 
passing a reference when it was expected.   This is a common concept 
with strong type-casting compilers, i.e. C/C++.

I recall talking it over with some PHP veteran users helping with adding 
direct PHP support and the only reason I saw for it was a "Coding Style" 
push or mindset towards OOPs and functional programming; x = func(y), as 
  oppose to func(x,&y);

>  All I know is it's slower in most (not all) situations. So the real 
>  question is: should there be a warning at all? And if so, shouldn't it 
>  be there by default?

Passing by reference should be faster, not slower since the latter 
requires data to be pushed into the stack.  But I see that as a moot 
point as both are natural considerations for programmers.

In general, unless something is absolutely critical, I always leaned 
toward the theory of "Less Surprises & Working Code."

I can see this more applicable to compiling PHP code or run time 
warnings for explicit PHP code.   For extensions, where the Programmer 
has to do a lot more to make parameter referencing work with ZEND in the 
first place, there is an explicit intent to expose an API with functions 
containing variable pointers.

In this case, IMO, the compromise might be to offer the option as an 
[Extension_name] option.

I think in the end Steve, users are going to do what it takes anyway. 
Set the option on to support some package they really, really, really 
want to use.  I mean, they might not have a choice in the matter.  I 
don't see a security reason for it.  Its more of a coding style issue 
and users really don't give a hoot as long the package works for them.

My 2 pennies of course :-)

-- 
Hector


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php