hi Rasmus,
I understand the point you made below - you have made this argument before
and I, for one, accepted it as valid when I first read the discussion
on internals - which is why I avoided ranting about that (and changes like it)
But I am wondering what if any your views might be on the original rant (mine)
regarding purism/strictness that [I feel] is creeping into php for no good
(read 'pragmatic') reason?
as an example - I have in the past argued that discontinuing the ability to
define static methods in interfaces was against the grain and was given the
reply 'you don't understand OO fix your code' - in the last couple of weeks
static interface methods were reintroduced to help in a situation highlighted
by Derick R. I have had pretty much the same experience regarding late static
binding - to which (though nothing to do with my pleas) has finally been capitulated
for inclusion in php6.... not inducive to an optimal uptake of php5 which given
the length of time it's been out is rather dismal when compared to the speed at
which php4 was taken up.
if you agree at all with my postulation then maybe you also see some need
to address the issue?
kind regards,
Jochem
Rasmus Lerdorf wrote:
Robert Cummings wrote:
Well there "was" a segfault, but that's fixed now, now the warning is
thrown because of some purist attitude that says it's incorrect to pass
a literal to a reference expecting parameter... I can see how that's an
issue in C with pointers, or in a strongly type language like Java, but
part of PHP's popularity is that while it shares a lot of functions with
C, it is neither C nor Java, but rather a much simpler system that
generally for all the novices out there "works well".
Stuff like this is a bug in your code. It has nothing to do with purism:
function inc_arg(&$arg) {
$arg++;
}
inc_arg(3);
You have specifically defined your function to modify the argument yet
you pass it something that has no storage and thus there is no way to
use that modification. For the most part I agree that we need to keep
the language as flexible and forgiving as possible, but where we are
able to detect code that obviously doesn't do what the programmer
intended, it is tremendously helpful to get a descriptive error.
As far as functions returning references, you are right that returning a
literal there sometimes makes sense, but this can also hide a bug which
is why this only throws a notice.
You could argue that we could try to look ahead and see what is actually
done with the passed argument to see if it is modified, or that we could
try to figure out whether the returned reference is actually used as
such, but that is technically extremely difficult given the way things
work internally. So given the choice between ignoring extremely
suspicious code like this and throwing an error/warning, I'd rather be
told about it and in the edge cases where I really do want the
equivalent of a NOP in my code, it isn't that hard to force it by adding
a dummy storage variable along with a comment explaining why you need to
do that.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
