The fact that this use of PHP is documented in the manual as a feature
www.php.net/manual/en/**language.oop5.basic.phphttp://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
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
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
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 -
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
On Monday 28 January 2013 21:46:27 Stas Malyshev wrote:
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.
I've seen that sentiment against using static methods several times now,
and it
On Monday, January 28, 2013 11:30 PM, Zeev Suraski wrote:
Alan,
Can you explain why you think it's a major BC break? The RFC suggested that
the BC break would be minimal and that the likelihood a lot of people used
it is very low. If you think differently and share it it might put it in a
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
