Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-05-26 Thread Ferenc Kovacs 
On Tue, Mar 26, 2013 at 6:45 PM, Ferenc Kovacs  wrote:

>
>
>
> On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes wrote:
>
>> I've opened the vote for the "remove calls from incompatible context" RFC:
>>
>> https://wiki.php.net/rfc/**incompat_ctx#vote
>>
>> --
>> Gustavo Lopes
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> 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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-03-26 Thread Ferenc Kovacs 
On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes wrote:

> I've opened the vote for the "remove calls from incompatible context" RFC:
>
> https://wiki.php.net/rfc/**incompat_ctx#vote
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (with patch)

2013-02-05 Thread Alan Knowles 
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



On Thursday, January 31, 2013 07:41 PM, Ferenc Kovacs wrote:

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..


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.



diff --git a/Zend/zend_vm_def.h b/Zend/zend_vm_def.h
index 27b2bd1..c6fcdcb 100644
--- a/Zend/zend_vm_def.h
+++ b/Zend/zend_vm_def.h
@@ -2591,12 +2591,20 @@ ZEND_VM_HANDLER(113, ZEND_INIT_STATIC_METHOD_CALL, 
CONST|VAR, CONST|TMP|VAR|UNUS
!instanceof_function(Z_OBJCE_P(EG(This)), ce TSRMLS_CC)) {
/* We are calling method of the other (incompatible) class,
   but passing $this. This is done for compatibility with 
php-4. */
-   if (call->fbc->common.fn_flags & ZEND_ACC_ALLOW_STATIC) 
{
-   zend_error(E_STRICT, "Non-static method 
%s::%s() should not be called statically, assuming $this from incompatible 
context", call->fbc->common.scope->name, call->fbc->common.function_name);
-   } else {
+
+   zend_class_entry *top_ce = ce;
+   
+   if (!(call->fbc->common.fn_flags & 
ZEND_ACC_ALLOW_STATIC)) {
/* An internal function assumes $this is 
present and won't check that. So PHP would crash by allowing the call. */
zend_error_noreturn(E_ERROR, "Non-static method 
%s::%s() cannot be called statically, assuming $this from incompatible 
context", call->fbc->common.scope->name, call->fbc->common.function_name);
}
+   
+   while (top_ce->parent) top_ce = top_ce->parent;
+   
+   /* if calling scope and target scope share the same 
parent, do not show warning */
+   if (!instanceof_function(Z_OBJCE_P(EG(This)), top_ce 
TSRMLS_CC)) 
+   zend_error(E_DEPRECATED, "Non-static method 
%s::%s() should not be called statically, assuming $this from incompatible 
context", call->fbc->common.scope->name, call->fbc->common.function_name);
+   }  
}
if ((call->object = EG(This))) {
Z_ADDREF_P(call->object);
-- 
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)

2013-01-31 Thread Ferenc Kovacs 
>
> 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..
>

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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)

2013-01-30 Thread Sanford Whiteman 
>> 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)

2013-01-30 Thread Alan Knowles 
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)

2013-01-30 Thread Stas Malyshev 
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)

2013-01-30 Thread 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 r

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-30 Thread Ferenc Kovacs 
On Wed, Jan 30, 2013 at 10:50 AM, Lester Caine  wrote:

> Gustavo Lopes wrote:
>
>> I've opened the vote for the "remove calls from incompatible context" RFC:
>>
>> https://wiki.php.net/rfc/**incompat_ctx#vote
>>
>
> 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 ?


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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-30 Thread Lester Caine 

Gustavo Lopes wrote:

I've opened the vote for the "remove calls from incompatible context" RFC:

https://wiki.php.net/rfc/incompat_ctx#vote


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

--
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)

2013-01-29 Thread Patrick Schaaf 
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)

2013-01-28 Thread Stas Malyshev 
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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)

2013-01-28 Thread Alan Knowles 


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

2013-01-28 Thread Pierre Joye 
On Jan 28, 2013 8:41 PM, "Stas Malyshev"  wrote:
>
> 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.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Stas Malyshev 
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

-- 
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

2013-01-28 Thread Pierre Joye 
Lester,

On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine  wrote:

> 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.

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

-- 
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

2013-01-28 Thread Ferenc Kovacs 
On Mon, Jan 28, 2013 at 5:37 PM, Lester Caine  wrote:

> Ferenc Kovacs wrote:
>
>>
>> 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.
>>
>
> 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!


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 the E_DEPRECATED ones.


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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Lester Caine 

Ferenc Kovacs wrote:


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.


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

--
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

2013-01-28 Thread Pierre Joye 
On Mon, Jan 28, 2013 at 4:59 PM, Pierre Joye  wrote:
> hi,
>
> On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes  wrote:
>> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye 
>> wrote:
>>
>>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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

-- 
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

2013-01-28 Thread Pierre Joye 
hi,

On Mon, Jan 28, 2013 at 4:56 PM, Gustavo Lopes  wrote:
> On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye 
> wrote:
>
>> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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

-- 
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

2013-01-28 Thread Gustavo Lopes 
On Mon, 28 Jan 2013 16:45:43 +0100, Pierre Joye   
wrote:



On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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

--
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

2013-01-28 Thread Pierre Joye 
On Mon, Jan 28, 2013 at 4:49 PM, Pierre Joye  wrote:
> On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski  wrote:
>
>> 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

-- 
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

2013-01-28 Thread Ferenc Kovacs 
On Mon, Jan 28, 2013 at 4:45 PM, Pierre Joye  wrote:

> hi Zeev,
>
> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Pierre Joye 
On Mon, Jan 28, 2013 at 4:47 PM, Zeev Suraski  wrote:

> 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

-- 
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

2013-01-28 Thread Ferenc Kovacs 
On Mon, Jan 28, 2013 at 4:32 PM, Lester Caine  wrote:

> 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.


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'
> by E_STRICT is 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 switching E_STRICT off 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_STRICT if 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

RE: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Zeev Suraski 
> -Original Message-
> From: Pierre Joye [mailto:pierre@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
> context
>
> hi Zeev,
>
> On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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.

What does it mean then?  That implementing this RFC waits for 6.0 or that
it was invalid in the first place?

Zeev

-- 
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

2013-01-28 Thread Pierre Joye 
hi Zeev,

On Mon, Jan 28, 2013 at 4:30 PM, Zeev Suraski  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.

Cheers,
--
Pierre

@pierrejoye

-- 
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

2013-01-28 Thread Alan Knowles 

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



On Monday, January 28, 2013 11:01 PM, Gustavo Lopes wrote:

On Mon, 28 Jan 2013 15:49:26 +0100, Alan Knowles  wrote:


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.




--
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

2013-01-28 Thread Lester Caine 

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

--
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

2013-01-28 Thread Zeev Suraski 
> -Original Message-
> From: Alan Knowles [mailto:a...@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
> context
>
> 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

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

-- 
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

2013-01-28 Thread Leigh 
On 30 July 2012 18:31, Gustavo Lopes  wrote:

> 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.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Leigh 
On 28 January 2013 14:49, Alan Knowles  wrote:

> 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 :)


On 20 January 2013 19:17, Gustavo Lopes  wrote:

> I've opened the vote for the "remove calls from incompatible context" RFC:
>
> https://wiki.php.net/rfc/incompat_ctx#vote
>

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.


On 28 January 2013 14:17, Alan Knowles  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
>
>
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.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Ferenc Kovacs 
On Mon, Jan 28, 2013 at 3:49 PM, Alan Knowles  wrote:

> 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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Gustavo Lopes 

On Mon, 28 Jan 2013 15:49:26 +0100, Alan Knowles  wrote:


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

--
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

2013-01-28 Thread Alan Knowles 
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  wrote:

>On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles 
>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=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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Ferenc Kovacs 
On Mon, Jan 28, 2013 at 3:17 PM, Alan Knowles  wrote:

>
> 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

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Gustavo Lopes 

On Mon, 28 Jan 2013 15:17:21 +0100, Alan Knowles  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=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

--
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

2013-01-28 Thread Alan Knowles 

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  wrote:

>On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes
>
>wrote:
>
>> I've opened the vote for the "remove calls from incompatible context"
>
>> RFC:
>>
>> https://wiki.php.net/rfc/incompat_ctx#vote
>>
>
>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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

2013-01-28 Thread Gustavo Lopes 
On Sun, 20 Jan 2013 20:17:05 +0100, Gustavo Lopes   
wrote:


I've opened the vote for the "remove calls from incompatible context"  
RFC:


https://wiki.php.net/rfc/incompat_ctx#vote



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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php