Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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 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.. I stand corrected, I said that (AFAIR) is an undocumented feature, but as you pointed out, it is documented since (at least) 2004: http://svn.php.net/viewvc/phpdoc/en/trunk/language/oop5/basic.xml?view=markuppathrev=166424 (there is a typo here, so it is called a psudo variable) And an example was added in 2005: http://svn.php.net/viewvc?view=revisionrevision=178495 by sean (funny commit comment: 'document seemingly-odd $this behaviour'). The E_STRICTs were added to the examples in 2009: http://svn.php.net/viewvc?view=revisionrevision=288217 This doesn't really change my opinion, but it means that there could be more people using this feature than I/we assumed. Given the fact that this already spits E_STRICT(and E_STRICT is part of E_ALL since 5.4) and both E_STRICT and E_DEPRECATED is disable in our php.ini-production, I would say that changing this from E_STRICT to E_DEPRECATED has no direct impact to the userland. But we can use this change to sample the people using this feature and based on the feedback we can decide whether we want to keep this or remove it for the next version. So my opinion is that we should stick to the vote and deprecate this feature but update the RFC and remove the part removing it in the next version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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...
Not going to sound off on other subtopics in this thread, about which
my feelings are mixed, but your note here is pretty strange. I agree
with Stas and others that you are already using an antipattern, so if
a major justification is that you need to manually authorize a
subclass to call the super, you don't need to override and throw in
every possible subclass, how about something like this instead to
whitelist:
interface preservable
{
public function addPreserveText();
}
abstract class section {
public function addPreserveText()
{
if (!isset(class_implements($this)[preservable]))
throw new Exception(can't call super from disallowed
subclass);
echo ready to rumble;
}
}
class footer extends section implements preservable {}
class header extends section {}
$myfoot = new footer();
$myfoot-addPreserveText(); // ready to rumble
$myhead = new header();
$myhead-addPreserveText(); // error
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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 always falls short of mentioning the third ingredient it brings to the table: inheritance. In our internal development we often use static-method-only classes, converting stuff previously required and global in that namespace-like-with- autoload fashion, and most of the time this _additionally_ permits us to refactor some conditional spaghetti mess into a small-set-of-subclasses inheritance setup that makes the fundamental conditions stand out a lot more clearly than sprinkling conditionals all over the place. To my thinking, using just classes and static methods is absolutely fine OO, simply considering each class to be a singleton object I do not need to instantiate at all. Regarding the discussion at hand (that $this thing) I wasn't even aware of the old behaviour, and factoring common code in our small-set-of-subclasses approach was the #1 reason to switch to PHP 5.4 some month ago, so that we could use traits for that. best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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 different light. Zeev This is an example of recently written code that from my understanding will now generate a E_DEPRECATED based on that RFC http://git.roojs.org/?p=pear;a=blob;f=Document/Word/Writer/Section/TextRun.php;hb=HEAD#l136 The concept there is Class ... Section Class ...Section_Footer extends ...Section Class ...Section_TextRun extends ..Section The method 'addPreserveText' is in Footer, however the method is needed in TextRun, so It's called statically (expecting $this to be similar, as the both extend the same base class). Yes, this could be fixed other ways (putting addPreserveText to 'Section') or a Trait, however the current method has a number of benefits a) the code is easy to follow - hence we can get anyone to understand it quickly. b) putting it in the parent class would expose it to the children (where it may not be valid) c) traits would add a little extra complexity, and make the code a little bit more difficult to follow. 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... Regards Alan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
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. If addPreserveText() uses anything from Footer, it should not be called from TextRun, but if it does not, it should be in Section. I certainly disagree that the code that calls method of Footer from TextRun is easy to follow - 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. As far as I know, no OO languages allow to do such things. 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 :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
