Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65521
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: <5109A834.6070503@roojs.com>
Date: Thu, 31 Jan 2013 07:09:40 +0800
Organization: Roo J Solutions Limited
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
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>
In-Reply-To: <51076233.2040507@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)

Rebuttal inline... - and better solution at end...

On Tuesday, January 29, 2013 01:46 PM, Stas Malyshev wrote:
> Hi!
>
>> I've used this in other places, it's basically lightweight traits, and
>> has always been perfectly valid code. There does not seem to be a clear
>> justification for deprecating it other than, It's not the way 'some'
>> people like code to work...
> Well, I think the reason is that this code is unsafe and goes against
> the principles of OO. I understand that there's a tendency to use OO as
> a neat way to namespace global functions and autoload them, but that's
> not how it is supposed to work.
Actually even If I used Trait's here, the code would be no safer, this 
is kind of the absurdity of traits and this E_STRICT error, since PHP is 
not a compiled language, the engine can not really determine if 
accessing $this inside the trait method is really compatible scope. 
Unless I'm wrong I suspect there are no checks  in traits to determine 
if the method tries to call methods, or write properties that are not 
defined in the trait until runtime, when it explodes..

It's only suggested that it might be compatible by adding to the class. 
This is why the E_STRICT warning is absurd in the first place, just 
because the writer hints that $this is compatible in traits does not 
mean it really is.. It is no better that the previous way of doing this.

The fact that this use of PHP is documented in the manual as a feature
www.php.net/manual/en/language.oop5.basic.php

And mentions that it will elicit a E_STRICT error - does not indicate 
that it would be DEPRECATED, I'm assuming that has been documented for 
years, and only recently (a year or two) has the E_STRICT comment been 
added.
There is also no real Justification for the E_STRICT message = see 
suggestion at end..

> If addPreserveText() uses anything from Footer, it should not be called
> from TextRun, but if it does not, it should be in Section.
No, if it was in Section, all the child classes would have to override 
it and throw errors. That results in quite a bit of pointless 
boilerplate code to solve a problem that has just been created by this 
change (and really the original E_STRICT one). If the code path results 
in a call to addPreserveText in the other classes, it's a pretty serious 
error, and we need to catch that quick...

>   I certainly
> disagree that the code that calls method of Footer from TextRun is "easy
> to follow" -
Easy to follow? the code reads
.....Section_Footer::addPreserveText()
That says' I'm going to call addPreserveText in section_footer, that's 
about the most obvious bit of code I've ever seen....

> I'd be very surprised seeing such code and would
> immediately think it's some kind of bad copy-paste from one class to
> another. I understand that this hack works for you - but language
> usually enforce some rules of what you can and can not do, according to
> some guiding principles. Having this hack goes again those principles.
I'm not sure what these principles are sometimes, they seem to say we 
need to implement features from compiled languages, and yet we can not 
do compile time checks as we are a dynamic language. So we are going to 
pretend that stuff works because we have change the syntax a bit.
> As far as I know, no OO languages allow to do such things.

I did a testable version in javascript the other day. - it's similar to 
this..
a = { function A() { console.log(this.value); }};
b = {  function B() { a.A.call(this); }};
c = new b();
c.B();

Javascript uses .call() to modify the scope on the recieving end. I't 
not that different to PHP currently, however PHP has been slightly 
better as it does not need to send the scope..

It's not used alot in this way, but it handy for a duck patching methods 
onto classes. - normally you would just do b.A = a.B ....

> I note that we have people here constantly criticizing us for not
> changing the names of all functions in order to satisfy their esthetic
> sense, but once we change something that obviously for nearly everybody
> (see vote) shouldn't even be there and never was intended to work this
> way - we get criticized again for breaking stuff :)
An almost secret vote, that as I mentioned before, this was unfortunate, 
that nobody spotted this before, There was objections when it was first 
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.

At least I managed to catch this one before it get's to  a release..... 
is_a ???

I've ignored this problem for a while, I suspect this is the last of the 
E_STRICT absurd uses that is stopping me from turning it on. In this 
particular case it's pedantic, and goes against the idea of getting shit 
done.

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.

That would make this method of doing Multiple Inheritance at small bit 
more reliable than trait's. And would at least be a correct warning... 
rather than the current one which should say something like
"Call from possibly incompatible scope, but I'm not sure as I did not 
really check"

Regards
Alan