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
