Re: [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
| From: | Alan Knowles | Date: | Thu, 31 Jan 2013 01:42:55 +0000 |
| Subject: | Re: [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-65523@lists.php.net to get a copy of this message | ||
Top posting as the discussion was going a bit off topic. (Yes there was a vote, but the rfc could do with some refinements.)
This is an illustration of the proposed change to the RFC, and the absurdity of how trait's allow incompatible scopes, and give no similar warning
Example1 - illustrates the problem that the traits hides the problems that E_DEPRECATED/E_STRICT is trying to show.
Obviously in a compiled language this would be picked up, but we can not do it in a scripted language.
trait test {
function a() {
// b does not exist in testb - so in theory $this is in an incompatible scope.
// however no warning is raised as it's in a trait. - it just says Fatal error....
$this->b();
}
}
class testb {
use test;
function testb() {
$this->a();
}
}
new testb();
Example2 - what should work without warnings.
class base { }
class testa extends base {
var $v = 'testa';
function a() {
// usage of $this elicits E_STRICT
// however, testa and testb share the same parent and may be reasonably compatible.
// suggested fix - do not emit warning if $this (testb) and (testa) both have the same top level parent or interface...
// in all other scenarios - emit E_DEPRECATED (eg. if $this == null, or some unrelated class)
echo $this->v;
}
}
class testb extends base {
var $v = 'testb';
function testb() {
testa::a();
}
}
new testb();
Regards
Alan
On Thursday, January 31, 2013 08:00 AM, Stas Malyshev wrote:
Hi!I did a testable version in javascript the other day. - it's similar to this..Javascript is not really an OO language. It has objects, but it doesn't really follow or enforce any of OO paradigms. It's prototype-based, so things work differently there.An almost secret vote, that as I mentioned before, this was unfortunate, that nobody spotted this before, There was objections when it was firstThere was not any "secret vote". It was announced on the list, just as any other votes are. I understand one can miss stuff, but there was nothing secret, it was standard process.proposed, but that was not really mentioned in the rfc, and the vote was done in 7 days with one message mention the start of the vote.How many messages are necessary? Are we supposed to spam the list for weeks in hope people would actually read it? I think one is perfectly enough.Why not make that E_STRICT actually useful, and change it so it only occurs if the $this of the calling scope and the function do not share the same top level parent.What common top level parent has to do with it? If you call common parent function, you don't need to call into wrong scope - you can call it from the same scope. It's when you want to call method that is not in your scope but pretend that it is - then you need wrong scope call. And it's not supposed to work this way - you're not supposed call methods on objects that don't have this method in their class.