Inline. Quoted portion edited extensively for brevity. > -----Original Message----- > From: Michael Morris [mailto:dmgx.mich...@gmail.com] > > $a = 123; > function foo ( int $i ) {} > foo($a); // OK > > foo("123"); // NOTICE, because "123" is a constant > > $a = "456"; > foo($a); // OK, because conversion is lossless >
-1. Should be no notice in either of the last two cases. Raising the notice when a constant is used is inconsistent and confusing. I also doubt that this sort of implementation is even possible without some pretty massive internal changes. Not worth it IMO. > int $a = 123; // "type locked" to integer > > $a = "456"; // E_NOTICE > > $a = "Hello World"; // E_NOTICE I'm very dubious on hinting variables. This would require storing additional data with the variable, which (as far as I can see) would break binary compatibility (same problem as taint). I don't see much of a use for this most of the time, with the notable exception of member variables (sometimes type locking a class member would be really nice.) Also, there should be no notice in case 2 (same argument as before with functions) Notice on case 3 is fine > > unset($a); > $a = "Hello World"; // OK, because of unset > > int $a; // E_NOTICE, $a had a value which can't convert without loss of data. This just seems silly to me. Trying to declare int $a after $a is already present and set is a nonsense construct. I think E_RECOVERABLE_ERROR should be raised on this and $a should be set to null regardless of convertibility (the more likely intent and meaning of that line of code) in case the error handler decides to continue execution. > scalar $a; -1, I don't think we need this any more than we need an explicit "mixed" type. Saying "this function needs a number or it can't work" is one thing. There is a sound logical foundation for that. A scalar could be anything though. You're still going to have to check types to decide what you really have and alter code paths as appropriate. > And if we don't want to unset $a but rather restore $a to behaving like a > scalar, that is how it would be done. -1, same argument as int $a; when $a is already set. This is a nonsensical construction. You are using a variable declaration like a typecast and reusing a variable. This is sloppy and confusing to reduce code in a badly structured edge case. If you really honestly must untype a local variable, you can always do this instead: $tmp = $a; unset($a); $a = $tmp; BUT, if there is any reason why you would actually need to untype a variable, then there are much bigger problems. This shouldn't be handled in the core language. > So, in closing this ramble, if I right a db library whose functions are > datatyped > you might see more notices, but the code will work and notices are usually > suppressed > by default (yes, I know about the RFC to change that) If using types causes a large number of unnecessary notices that's a spec problem. The core devs aren't going to accept that. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
