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
