I've opened the vote for the "remove calls from incompatible context" RFC:
https://wiki.php.net/rfc/incompat_ctx#vote
--
Gustavo Lopes
On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes glopes@nebm.ist.utl.pt
wrote:
I've opened the vote for the "remove calls from incompatible context"
RFC:
The RFC has been accepted unanimously. I'll implement it shortly. The
change is trivial for 5.5 (change E_STRICT to E_DEPRECATED); for master,
it should be fairly straightforward as well.
--
Gustavo Lopes
Holy crap, how did you sneak this through..
my apologies for deleting the = vote, but i could not work out how to revert it.
But this is a core php feature, for anyone who does not use traits.... We use this quite a bit, it may not be for purists, but it has worked perfectly for years. This is getting a bit silly, change for change sake....
Regards
Alan
Gustavo Lopes glopes@nebm.ist.utl.pt wrote:
On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes
glopes@nebm.ist.utl.pt
wrote:I've opened the vote for the "remove calls from incompatible context"
RFC:
The RFC has been accepted unanimously. I'll implement it shortly. The
change is trivial for 5.5 (changeE_STRICTto E_DEPRECATED); for
master,
it should be fairly straightforward as well.--
Gustavo Lopes--
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
my apologies for deleting the = vote, but i could not work out how to
revert it.
No problem, the result is still available at
https://wiki.php.net/rfc/incompat_ctx?rev=1359379541
I don't know want to know what you were trying to do, though...
But this is a core php feature, for anyone who does not use traits....
We use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change
sake....
I'm not discussing this again on the merits, but note that by the time
this feature is removed, no PHP version without traits will be maintained
anymore.
--
Gustavo Lopes
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days given to vote when every one is busy discussing a new property syntax.
Traits is cute, but this was a amazing feature of the PHP language, not obvious, but it's pretty similar to Javascript, not sure why it would be so confusing.....
Sorry for being contrary, but i was a but shocked that this was.going to be removed
Regards
Alan
Gustavo Lopes glopes@nebm.ist.utl.pt wrote:
On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles alan@roojs.com
wrote:my apologies for deleting the = vote, but i could not work out how to
revert it.
No problem, the result is still available at
https://wiki.php.net/rfc/incompat_ctx?rev=1359379541I don't know want to know what you were trying to do, though...
But this is a core php feature, for anyone who does not use
traits....
We use this quite a bit, it may not be for purists, but it has workedperfectly for years. This is getting a bit silly, change for change
sake....I'm not discussing this again on the merits, but note that by the time
this feature is removed, no PHP version without traits will be
maintained
anymore.--
Gustavo Lopes--
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7
days given to vote when every one is busy discussing a new property
syntax.Traits is cute, but this was a amazing feature of the PHP language, not
obvious, but it's pretty similar to Javascript, not sure why it would be
so confusing.....Sorry for being contrary, but i was a but shocked that this was.going to
be removed
You had more than 6 months to voice your concerns. There was a discussion
when the feature was proposed during summer. I'm sorry you did not notice
it, but I can't be spamming the list every once in a while to maximize the
number of people that are aware of what's going on.
Concerns about voting periods not having an upper bound notwithstanding,
there was nothing remotely irregular about the way the process was
conducted. I therefore find your comments about "sneaking this in" rather
odd. Blame yourself instead.
Again, I'm not commenting on the merits.
--
Gustavo Lopes
Ok, just checked the mailing list (and sorry for top-posting)
July 31st. RFC announced
Jul 31st - 6 or 7 mails at least one very negative, a couple for it.
August 1,3,5,6 - 5 or 6 emails getting a bit off-topic.
Jan 21st - call to vote (single email - no-one replied on list)... - got
15 +1 votes
Jan 28th - announced success..
I know it's not deliberate, but it looks like this change is just a BC
disaster waiting to happen, anyone who has been using PHP for more that
a few years, before traits, knows this is how to simulate multiple
inheritance, it's basically textbook PHP for some of us old boys.. ;)
It looks like the justification in the RFC is basically it's a WTF for
beginners. Sorry, but this is pretty identical to javascript behavior
(which does take some understanding, but is very powerful), so there is
no WTF, or surprise, once you seen it done, and understand it..
If you where suggesting that calling a non-static method from global
scope would cause some kind of E_DEPRECIATED, I'd agree, it's a good
idea. but I'm not convinced that this proposal is particularly well
thought through.
Ok, that's all for tonight ;)
Regards
Alan
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7
days given to vote when every one is busy discussing a new property
syntax.Traits is cute, but this was a amazing feature of the PHP language,
not obvious, but it's pretty similar to Javascript, not sure why it
would be so confusing.....Sorry for being contrary, but i was a but shocked that this was.going
to be removedYou had more than 6 months to voice your concerns. There was a
discussion when the feature was proposed during summer. I'm sorry you
did not notice it, but I can't be spamming the list every once in a
while to maximize the number of people that are aware of what's going on.Concerns about voting periods not having an upper bound
notwithstanding, there was nothing remotely irregular about the way
the process was conducted. I therefore find your comments about
"sneaking this in" rather odd. Blame yourself instead.Again, I'm not commenting on the merits.
I was trying to vote against, for what it's worth.
trying to re-open the vote and voting after Gustavo announced that the
voting was closed?
that's sounds a little bit weird.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.
personally I don't think it is a major BC break, AFAIR it is an
undocumented feature, it is marked by E_STRICT, and for the next release
this change will be only bumping from E_STRICT to E_DEPRECATED so anybody
out there depending on this will be notified and has time to deal with the
issue before the next release after 5.5.
closing the votes after 7 days is fine, and I think it wasn't closed to
rush the decision but it seemed that nobody was against it.
Traits is cute, but this was a amazing feature of the PHP language, not
obvious, but it's pretty similar to Javascript, not sure why it would be so
confusing.....
because $this doesn't make sense in a static call, and assuming the caller
methods scope isn't something what you would guess beforehand trying it out.
it is unintuitive and you will be surprised that it works when you first
encounter this.
Sorry for being contrary, but i was a but shocked that this was.going to
be removed
I think that if you have concerns it is better to talk it over so if we
missed something then it will brought forth.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.
See other thread by Zeev :)
I've opened the vote for the "remove calls from incompatible context" RFC:
Gustavo, it's probably a good idea in future to be a little more verbose
about the content of an RFC. The original mail didn't really give much
context with what was being proposed, so was easily skimmed over I guess.
That said, it was announced through the correct channels, and if you see
and RFC and don't know what it's about, all you have to do is click it and
see.
But this is a core php feature, for anyone who does not use traits.... We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change sake....
So your code has been generating errors since 2006 and you didn't think to
fix it? E_STRICT is an error just like any other. Ok, probably shouldn't
start a discussion about this, but it was my first thought.
-----Original Message-----
From: Alan Knowles [mailto:alan@roojs.com]
Sent: Monday, January 28, 2013 4:49 PM
To: Gustavo Lopes; PHP Internals; Alan Knowles
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible
contextI was trying to vote against, for what it's worth.
It's a major bc break with no obvious value, and what appears to be 7 days
given to vote when every one is busy discussing a new property syntax.Traits is cute, but this was a amazing feature of the PHP language, not
obvious,
but it's pretty similar to Javascript, not sure why it would be so
confusing.....Sorry for being contrary, but i was a but shocked that this was.going to
be
removed
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
hi Zeev,
-----Original Message-----
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.
Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues for someone else, that's why we do not allow BC, in
general. Killing some outdated "security" features however may fit
better, but I am really not sure this one is worse the risk.
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Monday, January 28, 2013 5:46 PM
To: Zeev Suraski
Cc: Alan Knowles; Gustavo Lopes; PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from
incompatible
contexthi Zeev,
-----Original Message-----
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.Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues
for someone else, that's why we do not allow BC, in general. Killing
some
outdated "security" features however may fit better, but I am really not
sure
this one is worse the risk.
What does it mean then? That implementing this RFC waits for 6.0 or that
it was invalid in the first place?
Zeev
What does it mean then? That implementing this RFC waits for 6.0 or that
it was invalid in the first place?
Both, if the plan is to get that into 5.x.
--
Pierre
@pierrejoye
What does it mean then? That implementing this RFC waits for 6.0 or that
it was invalid in the first place?Both, if the plan is to get that into 5.x.
Let me clarify, in my previous mail, I meant 5.6, not 5.5. The RFC is
clear that 5.5 will only get a strict warning, which is perfectly
fine. However removing it in 5.6 is not allowed.
--
Pierre
@pierrejoye
hi Zeev,
-----Original Message-----
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.Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues for someone else, that's why we do not allow BC, in
general. Killing some outdated "security" features however may fit
better, but I am really not sure this one is worse the risk.Cheers,
Pierre
@pierrejoye
--
did you read the RFC?
we would only deprecate this feature in 5.5.
and we already have such changes in 5.5 like
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre.php@gmail.com
wrote:
-----Original Message-----
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.Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues for someone else, that's why we do not allow BC, in
general. Killing some outdated "security" features however may fit
better, but I am really not sure this one is worse the risk.
Sorry, this objection simply is not timely.
In order for this voting thing to work, votes have to have a strong degree
of finality. It would have to take a pretty strong new fact to overcome
that finality. Otherwise, people will not have incentives to look early
at the RFCs and the discussions will never end.
In any case, the interpretation of the release process RFC as to BC breaks
has been rather lax. 5.4 introduced pretty disruptive BC breaks like
eliminating call-time pass-by-ref and changing the default encoding for
htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a
few (look at UPGRADING).
--
Gustavo Lopes
hi,
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre.php@gmail.com
wrote:-----Original Message-----
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.Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues for someone else, that's why we do not allow BC, in
general. Killing some outdated "security" features however may fit
better, but I am really not sure this one is worse the risk.Sorry, this objection simply is not timely.
In order for this voting thing to work, votes have to have a strong degree
of finality. It would have to take a pretty strong new fact to overcome that
finality. Otherwise, people will not have incentives to look early at the
RFCs and the discussions will never end.In any case, the interpretation of the release process RFC as to BC breaks
has been rather lax. 5.4 introduced pretty disruptive BC breaks like
eliminating call-time pass-by-ref and changing the default encoding for
htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a
few (look at UPGRADING).
I did not see any but the one about ini options we wanted to kill since years.
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.
--
Pierre
@pierrejoye
hi,
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye pierre.php@gmail.com
wrote:-----Original Message-----
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.Problem is that we do not allow BC break in 5.5, at all, minor or not.
Minor vs major BC is all relative, a minor BC for someone can create
large issues for someone else, that's why we do not allow BC, in
general. Killing some outdated "security" features however may fit
better, but I am really not sure this one is worse the risk.Sorry, this objection simply is not timely.
In order for this voting thing to work, votes have to have a strong degree
of finality. It would have to take a pretty strong new fact to overcome that
finality. Otherwise, people will not have incentives to look early at the
RFCs and the discussions will never end.In any case, the interpretation of the release process RFC as to BC breaks
has been rather lax. 5.4 introduced pretty disruptive BC breaks like
eliminating call-time pass-by-ref and changing the default encoding for
htmlentities/htmlspecialchars and new keywords. 5.5 will also introduce a
few (look at UPGRADING).I did not see any but the one about ini options we wanted to kill since years.
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.
ok, reading the list, there is nothing remotely comparable to what you
propose. However that's a non issue for 5.5 as this RFC only
introduces a strict warning. I would suggest to modify it to specify
that the removal will happen in the next major version.
--
Pierre
@pierrejoye
Hi!
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.
We need a better definition of BC break then. Is deprecating an existing
feature BC break? Is adding a notice BC break? If something like making
isset($string["foo"]) not return true anymore or fixing 64-bit numbers
handling BC break? Each can break code that relied on old way of doing
things. If we ban all of them for 5.x we'd need to have 6.0 much sooner,
since otherwise we'd be stuck with a lot of old unfixable warts for 5
years.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
If we introduced BC breaks other than those, then we'd to review them
and see why they have been introduced. But one thing is clear: we do
not allow BC breaks between 5.x and 5.x+1.We need a better definition of BC break then. Is deprecating an existing
feature BC break?
No, New warnings/notices are not BC breaks, fatal errors are.
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 aE_DEPRECATEDbased 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
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
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
Rebuttal inline... - and better solution at end...
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 thisE_STRICTerror, 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 originalE_STRICTone). 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
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_STRICTactually 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
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
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_STRICTactually 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.
Some of us have rather large bodies of code written over 10-12 years
that make significant use of calling $this from "incompatible
contexts" (i.e. we know it's compatible, but php doesn't).
Most consider such use a sin.
Could there be a compromise that would allow us evildoers to continue in
our evil ways without identifying and changing every use? Perhaps
"implements allowStaticCallsFromIncompatibleContexts" or somesuch? I
can imagine replacing every "class ..." with "class ... implements ...",
but identifying and changing every place we use an incompatible context
will be very, very unpleasant. We can figure out the places that are
hit most frequently using the logs, but that isn't necessarily a
complete list.
If this were a security issue, I'd understand making everyone go through
the pain. The RFC indicates the rationale is helping users find bugs.
It would be nice if those of us who would rather avoid a BC break than
easily find those bugs could do so.
Thanks for your consideration.
- Todd
Todd Ruth wrote:
Could there be a compromise that would allow us evildoers to continue in
our evil ways without identifying and changing every use? Perhaps
"implements allowStaticCallsFromIncompatibleContexts" or somesuch? I
can imagine replacing every "class ..." with "class ... implements ...",
but identifying and changing every place we use an incompatible context
will be very, very unpleasant. We can figure out the places that are
hit most frequently using the logs, but that isn't necessarily a
complete list.
It's all this 'implements' and the like which is complicating things along with
'the proper way of doing things'
The exercise that I am STILL working through is one where an objects function
used to be used statically as well as via $this ... if $this existed use it
otherwise generate a static result. As far as I am concerned still there was
nothing wrong, but I've gone through the exercise and written a HECK of a lot
more code switching a single function into three functions! A static call, a
$this call and often a further static function that has the shared code. I
forget now why the static call could not be used directly ... OH matched
parameters across all classes ... the base static has a subset of the class ones.
The main point here is that there was nothing functionally wrong with the PHP5.2
code, it had been doing it's job perfectly, leave E_STRICT off and the code
continues to work! I don't like this comparison with E_DEPRECATED, that is a
different concept in my mind ... E_STRICT is purely style police imposing other
peoples style choices, so the current debate IS appropriate, and it's nice to
hear a few more voices against some of this.
I can see that the resulting code changes improve the code, but I know I am
still missing a lot of the 'style changes' that I SHOULD be using simply because
of only hitting the E_STRICT warnings. It's a decent 'style' scanner that is
needed rather than these odd warnings in the core code :( To some extent
phpdocumenter helps here as the generated documents do flag up some of what as
been missed but certainly not all.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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 originalE_STRICTone). 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
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.phpAnd mentions that it will elicit a
E_STRICTerror - 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 theE_STRICTcomment been added.
There is also no real Justification for theE_STRICTmessage = 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=markup&pathrev=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=revision&revision=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=revision&revision=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
Attached should be a patch to illustrate the exception. (obviously needs
some tests modified, or created)
This removes the warning in the single situation where the calling scope
and target scope share the same top level parent. eg. Traits without the
baggage...
I think this is a reasonable change, It removes a warning which is only
partly true. In this small exception, It enables the language to behave
more like a scripting language, where yes, we do frequently have the
possibility of incompatible types, but only emits hints and notices
when they are really helpful and accurate.
Hopefully this means I can finally turn E_STRICT warnings on.
Regards
Alan
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.phpAnd mentions that it will elicit a
E_STRICTerror - 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 theE_STRICTcomment been added.
There is also no real Justification for theE_STRICTmessage = 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=markup&pathrev=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=revision&revision=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=revision&revision=288217This 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(andE_STRICTis part of
E_ALLsince 5.4) and bothE_STRICTandE_DEPRECATEDis disable in
our php.ini-production, I would say that changing this fromE_STRICTto
E_DEPRECATEDhas 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.
https://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
Gustavo, my apologies, the ORIGINAL mail did say a little more about it.
Holy crap, how did you sneak this through..
what do you mean by sneak? it was proposed and announced in the usual
channels.
my apologies for deleting the = vote, but i could not work out how to
revert it.
no problem, I've restored it, restoring an older version is done via
clicking the old version, clicking edit, and saving the page.
But this is a core php feature, for anyone who does not use traits.... We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change sake....
I've found this to be a huge wtf when you bump into, and already reported
by E_STRICT, so I was sold to the arguments made in the RFC.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
But this is a core php feature, for anyone who does not use traits.... We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change sake....I've found this to be a huge wtf when you bump into, and already reported
by E_STRICT, so I was sold to the arguments made in the RFC.
I think that this is the point here ...
In order for legacy code to even work, E_STRICT has to be disabled, so one does
not see any problem. That is the whole point of the switch? There is no
requirement to test code with the switch on, the wtf comes when something that
is 'protected' by E_STRICT is later removed! This was one of the major rework
areas on my own code and I can TOTALLY understand people taking the ADVISED
ROUTE of switching E_STRICT off as an alternative solution. NOW the question is,
what is the point of E_STRICT if it can't be avoided anyway?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Ferenc Kovacs wrote:
But this is a core php feature, for anyone who does not use traits.... We
use this quite a bit, it may not be for purists, but it has worked
perfectly for years. This is getting a bit silly, change for change
sake....I've found this to be a huge wtf when you bump into, and already reported
by E_STRICT, so I was sold to the arguments made in the RFC.I think that this is the point here ...
In order for legacy code to even work,E_STRICThas to be disabled, so one
does not see any problem.
Please Lester, could you stop pretending that E_STRICT errors will crash
your application and kill all the kittens?
There are a bunch of people (myself included) who tries to write E_STRICT
free code so that our application is fast and bugfree?
Yes, there are people who ignore E_STRICT and E_DEPRECATED and I agree that
having a zillion of those in the PEAR packages is a wrong thing.
But currently it is the way to remove a feature: deprecate it both in the
code and the manual, advertise in the release announcement, and remove it
in the next version, hence people who are interested in keeping up with the
changes will know what do they need to check and change.
That is the whole point of the switch? There is no requirement to test
code with the switch on, the wtf comes when something that is 'protected'
byE_STRICTis later removed!
E_STRICT was introduced in 5.0 E_DEPRECATED was introduced in 5.3, E_STRICT
was used for things that we use E_DEPRECATED now, but E_STRICT can be used
stuff other than deprecating features (like suggesting better alternatives:
http://lxr.php.net/xref/PHP_5_5/ext/date/php_date.c#1493 )
This was one of the major rework areas on my own code and I can TOTALLY
understand people taking the ADVISED ROUTE of switchingE_STRICToff as an
alternative solution.
What do you mean by ADVISED ROUTE?
I don't think we officially advised anybody for ignoring
errors/warnings/etc.
Maybe you mean that somebody from the php project advised you to ignore the
E_STRICT messages in a 3rd party library that you are using and not wanting
to clean up yourself?
NOW the question is, what is the point of
E_STRICTif it can't be avoided
anyway?
http://php.net/manual/en/errorfunc.constants.php
"Enable to have PHP suggest changes to your code which will ensure the best
interoperability and forward compatibility of your code."
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
Please Lester, could you stop pretending that
E_STRICTerrors will crash your
application and kill all the kittens?
There are a bunch of people (myself included) who tries to writeE_STRICTfree
code so that our application is fast and bugfree?
Yes, there are people who ignoreE_STRICTandE_DEPRECATEDand I agree that
having a zillion of those in the PEAR packages is a wrong thing.
But currently it is the way to remove a feature: deprecate it both in the code
and the manual, advertise in the release announcement, and remove it in the next
version, hence people who are interested in keeping up with the changes will
know what do they need to check and change.
I'm not going to go back and list the problems. E_STRICT errors DO cause
problems running legacy code. I've had plenty of white screens until E_STRICT
was switched back off in PHP5.4! Things that are just warnings in PHP5.3. Since
this is optional, some people 'opt' to ignore the warnings, just as they ignore
the E_DEPRECATED ones. The problem comes as in the case of $this in static
functions where the optional fixes are used to allow the code to run. PHP5.2
code works in 5.3 if warnings are hidden, but there is no guarantee the same
code will run in 5.4 and it may well now blow up in 5.5.
So I repeat the question, what is the point of providing a switch which disables
warning such as over the $this and then pulling the plug on it in a later
version. This is the exact sort of activity that I have been moaning about all
along. PHP5.3 and PHP5.4 introduced changes that should ideally have been
reserved for a major update. PHP5 code should run without problems and complain
in ANY later version of PHP5, not just some. That is what BC is all about! For a
LONG time we could even write PHP4 code that ran in PHP5.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Ferenc Kovacs wrote:
Please Lester, could you stop pretending that
E_STRICTerrors will crash
your
application and kill all the kittens?
There are a bunch of people (myself included) who tries to writeE_STRICT
free
code so that our application is fast and bugfree?
Yes, there are people who ignoreE_STRICTandE_DEPRECATEDand I agree
that
having a zillion of those in the PEAR packages is a wrong thing.
But currently it is the way to remove a feature: deprecate it both in the
code
and the manual, advertise in the release announcement, and remove it in
the next
version, hence people who are interested in keeping up with the changes
will
know what do they need to check and change.I'm not going to go back and list the problems.
E_STRICTerrors DO cause
problems running legacy code. I've had plenty of white screens until
E_STRICTwas switched back off in PHP5.4!
We told you that it shouldn't cause anything like that(except indirectly
like taking up more memory or executing time and hitting a limit, or having
a custom error handler which explicitly exit()s on an E_STRICT).
We also told you to check your error log and if by any chance is a bug
(what only you bumped into) then open a bugreport on
http://bugs.php.net/preferably attaching a simple reproduce script,
but you never did that as
far as I can tell.
So as far as we are concerned, E_STRICT works just fine.
Things that are just warnings in PHP5.3.
the only thing that was changed in 5.4 related to E_STRICT was that E_ALL
now includes E_STRICT, nothing else.
5.3 and 5.4 should behave in every other regard, if you think it isn't then
please open a bugreport.
Since this is optional, some people 'opt' to ignore the warnings, just as
they ignore theE_DEPRECATEDones.
yeah, those who don't wanna know or decide to ignore our runtime messages
about features going away are free to do that.
I can't see how and why should we change that, plus it would be a BC break.
The problem comes as in the case of $this in static functions where the
optional fixes are used to allow the code to run. PHP5.2 code works in 5.3
if warnings are hidden, but there is no guarantee the same code will run in
5.4 and it may well now blow up in 5.5.
the current releaseprocess RFC wouldn't allow that to happen in 5.x
So I repeat the question, what is the point of providing a switch which
disables warning such as over the $this and then pulling the plug on it in
a later version.
see above, we will (almost)always will deprecate a feature before removing
it.
taking away the option to silent those errors would be a pretty bad idea,
and would be a major BC (to do that you would have to also change the
current user error handler implementation, otherwise people would just
ignore from there).
removing a feature in a minor version is a different point, and it is
indeed a BC break and it isn't allowed by the current releaseprocess RFC.
personally I think that the current releaseprocess RFC will be either not
followed all the times or we will release major versions more frequently,
but time will tell.
This is the exact sort of activity that I have been moaning about all
along. PHP5.3 and PHP5.4 introduced changes that should ideally have been
reserved for a major update. PHP5 code should run without problems and
complain in ANY later version of PHP5, not just some. That is what BC is
all about! For a LONG time we could even write PHP4 code that ran in PHP5.
those versions were before us having formal RFCs, so features/changes was
done and merged in a case-by-case basis.
the major version bumps were always when the Zend Engine got rewritten, so
only when the extension API was broken.
the current releaseprocess in the other hand is a more stricter approach,
it requires a major version bump for any userland BC break.
so I think that you should be satisfied with the current situation as long
as the releaseprocess is followed.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Lester,
I'm not going to go back and list the problems.
E_STRICTerrors DO cause
problems running legacy code. I've had plenty of white screens until
E_STRICTwas switched back off in PHP5.4! Things that are just warnings in
PHP5.3.
To be honest I am tired of your 1st level support questions and
arguing. The white page syndrome is something that happens to any
newcomer, say for the 1st half day of his work. Stop now to hi jack
every discussion with totally pointless topics. You have questions
about how to setup a production server to do not be impacted by
notices? Ask on php-general or read the very well written
documentation.
--
Pierre
@pierrejoye
Gustavo Lopes wrote:
I've opened the vote for the "remove calls from incompatible context" RFC:
FINALLY realised why this was an itch I had to scratch.
Why just pick on one aspect of E_STRICT ? Surely the end point should be
removing all of the 'advisory warnings' blocked by E_STRICT rather than having a
vote on each one.
Flag as depricated ready to be removed in PHP6. So the discussion SHOULD be on
what else should be removed in PHP6 ?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Gustavo Lopes wrote:
I've opened the vote for the "remove calls from incompatible context" RFC:
https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote
FINALLY realised why this was an itch I had to scratch.
Why just pick on one aspect ofE_STRICT? Surely the end point should be
removing all of the 'advisory warnings' blocked byE_STRICTrather than
having a vote on each one.Flag as depricated ready to be removed in PHP6. So the discussion SHOULD
be on what else should be removed in PHP6 ?
as I mentioned before in another thread back in the pre 5.3 days E_STRICT
was indeed used in some cases for the same purposes as what E_DEPRECATED
does now, but there are exceptions so these should be reviewed case by case
basis for deprecation/removal instead of replacing every E_STRICT with
E_DEPRECATED.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:
I've opened the vote for the "remove calls from incompatible context" RFC:
https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote
--
Gustavo Lopes--
Hi Gustavo,
What is the status with this one?
AFAIK you never merged the change even though that the vote has ended, and
now we are in the feature freeze, so this can be a problem.
Am I missing something?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes glopes@nebm.ist.utl.ptwrote:
I've opened the vote for the "remove calls from incompatible context" RFC:
https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote
--
Gustavo Lopes--
Hi Gustavo,
What is the status with this one?
AFAIK you never merged the change even though that the vote has ended, and
now we are in the feature freeze, so this can be a problem.
Am I missing something?--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
It seems this won't make it to 5.5
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu