Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain roojs.com designates 202.81.246.113 as permitted sender)
Message-ID: <5109CC1F.3070507@roojs.com>
Date: Thu, 31 Jan 2013 09:42:55 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Internals <internals@lists.php.net>
References: <op.wq746rv5idpuyk@damnation.nl.lo.geleia.net> <op.wrmidlpiidpuyk@damnation.nl.lo.geleia.net> <debcd9bb-79f3-4b2c-aa66-9461018959c9@email.android.com> <op.wrmkyvlwidpuyk@damnation.nl.lo.geleia.net> <1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com> <be26f8067c25e21448eb7f3fc21809b0@mail.gmail.com> <51074873.5090600@roojs.com> <51076233.2040507@sugarcrm.com> <5109A834.6070503@roojs.com> <5109B421.4000805@sugarcrm.com>
In-Reply-To: <5109B421.4000805@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible
 context (example of real usage that will break)
From: alan@roojs.com (Alan Knowles)

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 first
> There 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.
>