Re: [PHP-DEV] [RFC] PHP 5.7

[Ferenc Kovacs]

On Tue, Dec 16, 2014 at 8:52 AM, Matteo Beccati  wrote:
>
> On 16/12/2014 05:07, Xinchen Hui wrote:
>
>> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds  wrote:
>>
>>> Good evening,
>>>
>>> There has been some debate about whether to make “PHP 5.7". I have made
>>> a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to
>>> be released at the same time as PHP 7, with no new features whatsoever.
>>>
>>>  I am wondering why we need that?  no new features
>>
>> I think we can extend 5.6 release cycle to avoid that..
>>
>
> I tend to agree with Xinchen here. A new minor release just to introduce a
> few deprecation messages? It sounds like a lot of work (it also need to be
> maintained) for little gain.
>
> I think that doesn't also match the plans of other (accepted?) RFCs that
> were targeted for 5.7. I think I've seen it many times.
>
>
>
We already has one accepted RFC which targets 5.7, and as I mentioned
before 5.7.0 wouldn't be featureless, but would contain the small
self-contained features which are currently targeting 5.6.x.
So 5.7.0 would be a minor version without new major features, but also no
BC break, would allow us to make 5.6 more stable, and be a stepping stone
for 7.0 with the deprecated errors.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] PHP 5.7

[Andrea Faulds]

Hi Matteo,

> On 16 Dec 2014, at 07:52, Matteo Beccati  wrote:
> 
> On 16/12/2014 05:07, Xinchen Hui wrote:
>> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds  wrote:
>>> Good evening,
>>> 
>>> There has been some debate about whether to make “PHP 5.7". I have made a 
>>> very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be 
>>> released at the same time as PHP 7, with no new features whatsoever.
>>> 
>> I am wondering why we need that?  no new features
>> 
>> I think we can extend 5.6 release cycle to avoid that..
> 
> I tend to agree with Xinchen here. A new minor release just to introduce a 
> few deprecation messages? It sounds like a lot of work (it also need to be 
> maintained) for little gain.

There should be very little work necessary. Deprecations are easy, and the 
changeset from 5.6 should be tiny at best. The only significant extra work is 
the added year of maintenance for the PHP 5 line.

> I think that doesn't also match the plans of other (accepted?) RFCs that were 
> targeted for 5.7. I think I've seen it many times.

Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation 
notices? I’m unaware of any.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] PHP 5.7

[Matteo Beccati]

On 16/12/2014 05:07, Xinchen Hui wrote:

On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds  wrote:

Good evening,

There has been some debate about whether to make “PHP 5.7". I have made a very 
simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at 
the same time as PHP 7, with no new features whatsoever.


I am wondering why we need that?  no new features

I think we can extend 5.6 release cycle to avoid that..


I tend to agree with Xinchen here. A new minor release just to introduce 
a few deprecation messages? It sounds like a lot of work (it also need 
to be maintained) for little gain.


I think that doesn't also match the plans of other (accepted?) RFCs that 
were targeted for 5.7. I think I've seen it many times.



Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

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

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

[Sebastian Bergmann]

Am 14.12.2014 um 19:35 schrieb Andrea Faulds:
> Thoughts?

 +1 for consistency :)

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Andrea Faulds]

Hi everyone,

> On 16 Dec 2014, at 00:15, Adam Harvey  wrote:
> 
> On 15 December 2014 at 16:09, Andrea Faulds  wrote:
>> The RFC can be found here: https://wiki.php.net/rfc/php57
> 
> Thanks for the taking the initiative on this.
> 
> On timing: I think we should release 5.7 in August (12 months after
> 5.6), rather than lining it up with 7.0. This gives us the opportunity
> to then focus our attention on 7.0 entirely for the crucial RC phase
> of that release. Given the limited scope of 5.7, we shouldn't need as
> long a testing cycle.

> On 16 Dec 2014, at 01:19, Kris Craig  wrote:
> 
> +1 on this.  I agree with Adam; it'd be better to line up 5.7 with the 
> support timeline for 5.6 and just handle 7's timeline separately.
> 

I’ve updated the RFC to target August 2015 for release. This would mean it 
would come out a year after 5.6, and the RC phase would be half as PHP 7’s.

> On 16 Dec 2014, at 05:51, Andrea Faulds  wrote:
> 
> Also, I failed to mention it in the RFC (will do so), but for any new 
> reserved words in PHP 7, we should also reserve them in 5.7.

I’ve also updated the to note that reserved words in PHP 7 can be pre-reserved 
in PHP 5.7.

Thanks for your comments!

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] PHP 5.7

[Levi Morrison]

>> There has been some debate about whether to make “PHP 5.7". I have made a 
>> very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be 
>> released at the same time as PHP 7, with no new features whatsoever.
>>
> I am wondering why we need that?  no new features
>
> I think we can extend 5.6 release cycle to avoid that..

Extending the PHP 5.6 release cycle doesn't give an opportunity to
raise different E_STRICT and E_DEPRECATED messages in preparation for
PHP 7.0. This may or may not be something you value, but it's
something I personally value.

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

[PHP-DEV] Re: [RFC] IntlChar class and intl_char_*() functions

[Sara Golemon]

On Mon, Nov 24, 2014 at 8:47 PM, Sara Golemon  wrote:
> While playing around with Andrea's unicode literals syntax proposal, I
> was reminded of just how little of ICU is exposed.  I've put up a
> short proposal for adding IntlChar exporting these APIs as static
> methods (with a matching non-oop interface).
>
> https://wiki.php.net/rfc/intl.char
>
Full implementation available now at
https://github.com/sgolemon/php-src/compare/intl.uchar
RFC updated to remove the functional API and clarify some things based
on what I learned while implementing.

Pay special attention to the #notes section regarding $limit which I
think is a somewhat non-PHP API.

-Sara

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Andrea Faulds]

Hi Xinchen,

> On 16 Dec 2014, at 04:07, Xinchen Hui  wrote:
> 
> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds  wrote:
>> Good evening,
>> 
>> There has been some debate about whether to make “PHP 5.7". I have made a 
>> very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be 
>> released at the same time as PHP 7, with no new features whatsoever.
>> 
> I am wondering why we need that?  no new features….

The reasoning behind this is to encourage people to switch to PHP 7 if they 
want new features.

> I think we can extend 5.6 release cycle to avoid that..

We could, but we wouldn’t be able to introduce deprecation notices in a 5.6 
micro, so we’d need a new minor releases.

Also, I failed to mention it in the RFC (will do so), but for any new reserved 
words in PHP 7, we should also reserve them in 5.7.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Kris Craig]

On Mon, Dec 15, 2014 at 8:19 PM, Leon Sorokin  wrote:
>
> On 12/15/2014 11:59 AM, Robert Williams wrote:
>
>> What world is this that you live in where every line of code that’s
>> written is fully unit-tested
>>
>
> You took my example too literally; forget the unit tests. Imagine the
> situation differently:
>
> 1. Someone wrote this function:
>
> function add_five_pct($num) {
>   return $num * 1.10;
> }
>
> 2. This function was then used to calculate profit margin and display
> retail prices on your site and business has been great! Unknowingly, you've
> been making 2x what was intended with no ill effects!
>
> 3. A new hire then went through this code on his own accord and decided,
> 'wait, this function is a bug!' and took it upon himself to fix it to '$num
> * 1.05'.
>
> Would you say the e-commerce site has been 'fixed' to work correctly?
> Should the dev be praised for fixing the clearly broken function without
> consulting anyone?
>
> I cannot come up with a clearer explanation of how a 'silent' code fix can
> foul up the bigger picture in non-beneficial ways. That's the scenario
> that's being discussed here. The main point of contention is, no one knows
> how much code exists in the wild that uses and relies on this misbehavior.
> My argument is 'negligible', others say it's 'non-negligible'. And the
> whole comedy is, no one can actually provide definitive numbers since
> nobody will ever know but a tiny portion of all source code that is out
> there, so all arguments stem from 'meta' evidence and personal experience.
>
>
> --
> Leon Sorokin
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Precisely why I suggested we do a poll and find out.  Polling is a valid
means of getting a reasonable accounting of a particular metric.  If we use
a sufficiently diverse and representative sample, we should easily be able
to get accurate enough results to settle this question once and for all.
The only cost is effort.

--Kris

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Leon Sorokin]

On 12/15/2014 11:59 AM, Robert Williams wrote:

What world is this that you live in where every line of code that’s written is 
fully unit-tested


You took my example too literally; forget the unit tests. Imagine the 
situation differently:


1. Someone wrote this function:

function add_five_pct($num) {
  return $num * 1.10;
}

2. This function was then used to calculate profit margin and display 
retail prices on your site and business has been great! Unknowingly, 
you've been making 2x what was intended with no ill effects!


3. A new hire then went through this code on his own accord and decided, 
'wait, this function is a bug!' and took it upon himself to fix it to 
'$num * 1.05'.


Would you say the e-commerce site has been 'fixed' to work correctly? 
Should the dev be praised for fixing the clearly broken function without 
consulting anyone?


I cannot come up with a clearer explanation of how a 'silent' code fix 
can foul up the bigger picture in non-beneficial ways. That's the 
scenario that's being discussed here. The main point of contention is, 
no one knows how much code exists in the wild that uses and relies on 
this misbehavior. My argument is 'negligible', others say it's 
'non-negligible'. And the whole comedy is, no one can actually provide 
definitive numbers since nobody will ever know but a tiny portion of all 
source code that is out there, so all arguments stem from 'meta' 
evidence and personal experience.


--
Leon Sorokin

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Xinchen Hui]

On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds  wrote:
> Good evening,
>
> There has been some debate about whether to make “PHP 5.7". I have made a 
> very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be 
> released at the same time as PHP 7, with no new features whatsoever.
>
I am wondering why we need that?  no new features

I think we can extend 5.6 release cycle to avoid that..

thanks
> The hope is that we can put this to a vote in 2 weeks’ time and settle the 
> matter, just as we did with the PHP 6/7 name vote, although perhaps slightly 
> less messily this time. ;)
>
> The RFC can be found here: https://wiki.php.net/rfc/php57
>
> Thanks!
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] PHP 5.7

[Kris Craig]

On Mon, Dec 15, 2014 at 4:20 PM, Andrea Faulds  wrote:

> Hi Adam,
>
> > On 16 Dec 2014, at 00:15, Adam Harvey  wrote:
> >
> > On 15 December 2014 at 16:09, Andrea Faulds  wrote:
> >> The RFC can be found here: https://wiki.php.net/rfc/php57
> >
> > Thanks for the taking the initiative on this.
> >
> > On timing: I think we should release 5.7 in August (12 months after
> > 5.6), rather than lining it up with 7.0. This gives us the opportunity
> > to then focus our attention on 7.0 entirely for the crucial RC phase
> > of that release. Given the limited scope of 5.7, we shouldn't need as
> > long a testing cycle.
>
> That’s a good point, it doesn’t actually have to line up with 7’s release
> and focus on 7.0 RC is crucial given the major changes.
>
> If others think this is a good idea, I’ll amend the RFC.
>
> Thanks!
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+1 on this.  I agree with Adam; it'd be better to line up 5.7 with the
support timeline for 5.6 and just handle 7's timeline separately.

--Kris

Re: [PHP-DEV] What ZEND_ACC_ALLOW_STATIC is supposed to do

[Rowan Collins]

On 16 December 2014 00:56:43 GMT, Tjerk Meesters  
wrote:
>Hi,
>
>I was looking at the documentation for DOMDocument::loadHTML() [1] that
>mentions the following:
>
>> This function may also be called statically to load and create a
>DOMDocument object. The static invocation may be used when no
>DOMDocument properties need to be set prior to loading.
>
>However, this can’t be done in strict mode [2]:
>
>> Strict Standards: Non-static method DOMDocument::loadHTML() should
>not be called statically in …
>
>This behaviour seems to be intended when ZEND_ACC_ALLOW_STATIC is used
>[3] and can be fixed by using ZEND_ACC_STATIC instead.
>
>My questions:
>
>1) Is that the right kind of fix? 
>2) Is ZEND_ACC_ALLOW_STATIC meant to be used only for BC? If not, why
>are we raising strict errors?

Surely that's just the same as a userland method which happens not to use $this 
("allow static") and one marked "static" so *must* be called statically?


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

[PHP-DEV] What ZEND_ACC_ALLOW_STATIC is supposed to do

[Tjerk Meesters]

Hi,

I was looking at the documentation for DOMDocument::loadHTML() [1] that 
mentions the following:

> This function may also be called statically to load and create a DOMDocument 
> object. The static invocation may be used when no DOMDocument properties need 
> to be set prior to loading.

However, this can’t be done in strict mode [2]:

> Strict Standards: Non-static method DOMDocument::loadHTML() should not be 
> called statically in …

This behaviour seems to be intended when ZEND_ACC_ALLOW_STATIC is used [3] and 
can be fixed by using ZEND_ACC_STATIC instead.

My questions:

1) Is that the right kind of fix? 
2) Is ZEND_ACC_ALLOW_STATIC meant to be used only for BC? If not, why are we 
raising strict errors?


[1] http://php.net/manual/en/domdocument.loadhtml.php 

[2] http://3v4l.org/JC7p0#v500 
[3] http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#1935 

Re: [PHP-DEV] [RFC] PHP 5.7

[Andrea Faulds]

Hi Adam,

> On 16 Dec 2014, at 00:15, Adam Harvey  wrote:
> 
> On 15 December 2014 at 16:09, Andrea Faulds  wrote:
>> The RFC can be found here: https://wiki.php.net/rfc/php57
> 
> Thanks for the taking the initiative on this.
> 
> On timing: I think we should release 5.7 in August (12 months after
> 5.6), rather than lining it up with 7.0. This gives us the opportunity
> to then focus our attention on 7.0 entirely for the crucial RC phase
> of that release. Given the limited scope of 5.7, we shouldn't need as
> long a testing cycle.

That’s a good point, it doesn’t actually have to line up with 7’s release and 
focus on 7.0 RC is crucial given the major changes.

If others think this is a good idea, I’ll amend the RFC.

Thanks!
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] PHP 5.7

[Adam Harvey]

On 15 December 2014 at 16:09, Andrea Faulds  wrote:
> The RFC can be found here: https://wiki.php.net/rfc/php57

Thanks for the taking the initiative on this.

On timing: I think we should release 5.7 in August (12 months after
5.6), rather than lining it up with 7.0. This gives us the opportunity
to then focus our attention on 7.0 entirely for the crucial RC phase
of that release. Given the limited scope of 5.7, we shouldn't need as
long a testing cycle.

Adam

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

[PHP-DEV] [RFC] PHP 5.7

[Andrea Faulds]

Good evening,

There has been some debate about whether to make “PHP 5.7". I have made a very 
simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released 
at the same time as PHP 7, with no new features whatsoever.

The hope is that we can put this to a vote in 2 weeks’ time and settle the 
matter, just as we did with the PHP 6/7 name vote, although perhaps slightly 
less messily this time. ;)

The RFC can be found here: https://wiki.php.net/rfc/php57

Thanks!
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Andrea Faulds]

Hi,

> On 15 Dec 2014, at 23:32, Johannes Schlüter  wrote:
> 
> On Mon, 2014-12-15 at 21:08 +0100, Ferenc Kovacs wrote:
>> there are two advantages for having 5.7 and having those deprecated
>> messages in 5.7:
>> 1, if we introduce the deprecated message in 5.6.x, some people will miss
>> it (for example debian jessie has 5.6.2)
> 
> So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see
> them on 7.0 as soon as possible.

Honestly, I don’t think Debian will switch to PHP 7, nor will any other distro, 
because it’s a new major version and it breaks things. `php` will probably 
continue to be PHP 5, they’ll add `php7`, prolong 5.6 or 5.7’s life for five 
years, and eventually switch `php` over to 7.

>> 2, would allow us to stabilize 5.6 instead of keep adding stuff to it
>> continuously .
> 
> New features in 5.6 should be rejected and added to 7.0 to give users
> more reasons to upgrade.

I agree on this one.

Thanks.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Johannes Schlüter]

On Mon, 2014-12-15 at 21:08 +0100, Ferenc Kovacs wrote:
> there are two advantages for having 5.7 and having those deprecated
> messages in 5.7:
> 1, if we introduce the deprecated message in 5.6.x, some people will miss
> it (for example debian jessie has 5.6.2)

So you want Debian to upgrade to 5.7 instead of 7.0? - I'D rather see
them on 7.0 as soon as possible.

> 2, would allow us to stabilize 5.6 instead of keep adding stuff to it
> continuously .

New features in 5.6 should be rejected and added to 7.0 to give users
more reasons to upgrade.

johannes



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

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Leon Sorokin]

On 12/15/2014 2:11 PM, Stanislav Malyshev wrote:


There's not that many breaking changes accepted, and each of them had to
be substantiated. "We had other breaking changes" is not a
substantiation. For example, "most uses of associativity are wrong ones"
- is, but that makes the idea of un-associating it even better, since
unlike changing the associativity, it actually makes the problem obvious
and easy to fix. Alternatively, of course, we could make a tool that
detects this and alerts the user, but making it loud still sounds better.
And the breakage we are discussing is not "trivial" - it's a logic
change which makes code silently take different codepath without anybody
knowing. In the world of BC breaks, this is one of the most evil ones.
So we should avoid it as much as possible.


The justification for not making breaking changes always grows as a 
function amount-of-code-in-the-wild which could possibly be relying on

bugs.

This situation results in a permanent conclusion of 'better-never' in 
lieu of 'better-now-than-later'. In PHP-land, the implication then is 
that this gridlock cannot be resolved even by major versions (IMO, one 
of very few reasons for major versions to exist *at all*).



Usually the burden of proof lays on whoever proposes the change. Note
that a lot of code is not public, especially for languages like PHP that
is used for websites - meaning, there's little reason to publicize any
code but reusable library code. And the fact that the change would not
break a handful of popular libraries doesn't mean it won't break scores
of websites whose source you can not see, but which are way more
important for the people using them than some library they don't use.

Yes, I understand that this means very high burden on somebody proposing
BC-breaking change, and it makes the development more conservative. It
is a high burden convince people that this change is worth the risk of
breaking potentially unknown code with unknown consequences.


Without telemetry, there is obviously no way of *ever* asserting that 
something is ripe for removal or even deprecation. So this burden of 
proof is unmeetable by definition.


--
Leon Sorokin


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

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Kris Craig]

On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > The fact that it *may* break *some* code that is used somewhere despite
> > documentation recommending against it (pretty much deprecating it
> > already for years) is a terrible reason not to re-evaluate the situation
> > given the huge opportunity to correct this.
>
> It *will* break some code. There's no chance that somebody somewhere
> doesn't use this. And the change would break it. Worse yet, he won't be
> able to know about it until the customer complains about code logic
> being broken.
>

On what basis are you making that claim with such certitude?  In all my
years, I have yet to encounter a single, solitary case where someone's
actually relying on PHP's wonky, counter-intuitive, non-standard
associativity with the ternary operator.  If such a one-in-a-billion
scripts does exist somewhere, it's likely some PHP 4 thing that hasn't been
touched in years.


>
> > The only thing that's bonkers here is outright refusal to make trivially
> > breaking changes (in addition to numerous other breaking changes already
> > accepted) simply for the sake of not breaking some 0.1% of outdated,
>
> There's not that many breaking changes accepted, and each of them had to
> be substantiated. "We had other breaking changes" is not a
> substantiation. For example, "most uses of associativity are wrong ones"
> - is, but that makes the idea of un-associating it even better, since
> unlike changing the associativity, it actually makes the problem obvious
> and easy to fix. Alternatively, of course, we could make a tool that
> detects this and alerts the user, but making it loud still sounds better.
> And the breakage we are discussing is not "trivial" - it's a logic
> change which makes code silently take different codepath without anybody
> knowing. In the world of BC breaks, this is one of the most evil ones.
> So we should avoid it as much as possible.
>
> > Rather than simply pointing to a 3-year-old close-reason, it would be
> > prudent to actually get statistics on how often this unexpected behavior
> > is relied upon in large, popular codebases. Packagist & Github, that
>
> Usually the burden of proof lays on whoever proposes the change. Note
> that a lot of code is not public, especially for languages like PHP that
> is used for websites - meaning, there's little reason to publicize any
> code but reusable library code. And the fact that the change would not
> break a handful of popular libraries doesn't mean it won't break scores
> of websites whose source you can not see, but which are way more
> important for the people using them than some library they don't use.
>
> Yes, I understand that this means very high burden on somebody proposing
> BC-breaking change, and it makes the development more conservative. It
> is a high burden convince people that this change is worth the risk of
> breaking potentially unknown code with unknown consequences. I think,
> however, it's better than actually suffering these consequences.
> Consider that however ugly this particular wart is, people has been
> living with it for almost 20 years, and it may be preferable for them to
> have somewhat ugly code than having broken code.
>

I don't think the "we've been sick so long we're used to it now" argument
is very compelling.  Some BC is expected in major revisions; and,
historically, we have been WAY too conservative about that, in my view.
When there's a major version and there's a BC-breaking change that either
fixes something many people have been complaining about or improves the
language in some other way without losing its identity, it should be a go.
Major revisions are when changes like this are supposed to be made because,
otherwise, these problems remain forever.  I don't think it's rational to
continue to ignore one of the most-requested fixes to PHP because one or
two people out there may be relying on the broken behavior-- and yes, it is
broken in the sense that it does not behave in the manner it's expected to
for a C-like syntax.

Didn't we talk about doing polls before?  We should do a poll on this in
the PHP community and see who, if anyone, has any code anywhere that relies
on this confusingly counter-intuitive behavior.  I would be amazed if even
one person answered yes to that.  So rather than continuing to guess and
make unfounded assumptions, why don't we just ask them and settle the
question here and now?

--Kris


> > It's short responses like this and the continued reliance on arguments
> > posed in a different era/landscape that compel me to reconsider my
> > continued participation in the PHP community at all.
>
> Sorry, but arguing from "do this or that or I'm quitting" does not seem
> a very strong argument to me. More drama does not help to evaluate the
> merits of changing the associativity of ?:. I think everybody here
> values the time of the volunteers that continue to contribute to the
> project, but I think keeping 

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Lester Caine]

On 15/12/14 20:08, Ferenc Kovacs wrote:
> there are two advantages for having 5.7 and having those deprecated
> messages in 5.7:
> 1, if we introduce the deprecated message in 5.6.x, some people will miss
> it (for example debian jessie has 5.6.2)
> 2, would allow us to stabilize 5.6 instead of keep adding stuff to it
> continuously .
And LTS versions can be ring fenced at 5.6 ... with just functional fixes.

Perhaps what is needed is a tool which does identify the problems in 5.X
code that need to be addressed in order to run clean in PHP7. Rather
than encumbering PHP7 with E_STRICT type warning/error code, PHP5.7
would be a test environment to replace that functionality. Once code
runs clean then one knows that it can be moved over? Style changes like
the 'incorrect ternary '?' associativity' function would be highlighted
so that BC problems are not silently changed. A properly documented
migration tool rather than a production release as I would not expect to
use PHP5.7 in a production environment!

-- 
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] On the road to PHP 5.7 , or not ?

[Patrick Schaaf]

Am 15.12.2014 20:43 schrieb "Zeev Suraski" :
>
> The extra pain associated with migrating to an interim
> version - that does nothing but spew warnings in the right places -and
> obviously doesn't have any of the other features of 7 - doesn't seem to
be a
> worthwhile experience for most users.

I dont't know about "most users", I can only speak for myself from our
small shop (in the big scheme of things...) production and development
experience. I compile PHP myself for our setup, and have a nice compilation
and deployment environment where I can easily throw new versions separately
onto developer hosts and production hosts. We made our codebase
E_STRICT|E_DEPRECATED-clean on the transition from 5.3 to 5.4, meanwhile
migrated to 5.5, and soon to 5.6, with almost no pain, by first running new
versions on developer machines and then on one of several production
servers, where possibly issues are visible pretty fast.

Now with PHP 7 promising potential for incompatibilities in a lot more
areas, it would be, to us, a really useful option to have a 5.7 that is
operationally fully compatible with 5.6 with added E_DEPRECATED for things
bound to break. With that we could A) rub the developers' noses in the
relevant deprecation messages for a while, _and_ run one or more rounds of
one-of-the-production -server tests, gathering more deprecation messages
there without fear of user visible effects.

I cannot judge how much effort such a 5.7 would be for you as developers,
and for the release managers, but I definitely would appreciate the effort,
and I'm 100% sure that it would speed up our eventual adoption of PHP 7 by
at least half a year, because the process would be much less risky.

best regards
  Patrick

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Stanislav Malyshev]

Hi!

> The fact that it *may* break *some* code that is used somewhere despite
> documentation recommending against it (pretty much deprecating it
> already for years) is a terrible reason not to re-evaluate the situation
> given the huge opportunity to correct this.

It *will* break some code. There's no chance that somebody somewhere
doesn't use this. And the change would break it. Worse yet, he won't be
able to know about it until the customer complains about code logic
being broken.

> The only thing that's bonkers here is outright refusal to make trivially
> breaking changes (in addition to numerous other breaking changes already
> accepted) simply for the sake of not breaking some 0.1% of outdated,

There's not that many breaking changes accepted, and each of them had to
be substantiated. "We had other breaking changes" is not a
substantiation. For example, "most uses of associativity are wrong ones"
- is, but that makes the idea of un-associating it even better, since
unlike changing the associativity, it actually makes the problem obvious
and easy to fix. Alternatively, of course, we could make a tool that
detects this and alerts the user, but making it loud still sounds better.
And the breakage we are discussing is not "trivial" - it's a logic
change which makes code silently take different codepath without anybody
knowing. In the world of BC breaks, this is one of the most evil ones.
So we should avoid it as much as possible.

> Rather than simply pointing to a 3-year-old close-reason, it would be
> prudent to actually get statistics on how often this unexpected behavior
> is relied upon in large, popular codebases. Packagist & Github, that

Usually the burden of proof lays on whoever proposes the change. Note
that a lot of code is not public, especially for languages like PHP that
is used for websites - meaning, there's little reason to publicize any
code but reusable library code. And the fact that the change would not
break a handful of popular libraries doesn't mean it won't break scores
of websites whose source you can not see, but which are way more
important for the people using them than some library they don't use.

Yes, I understand that this means very high burden on somebody proposing
BC-breaking change, and it makes the development more conservative. It
is a high burden convince people that this change is worth the risk of
breaking potentially unknown code with unknown consequences. I think,
however, it's better than actually suffering these consequences.
Consider that however ugly this particular wart is, people has been
living with it for almost 20 years, and it may be preferable for them to
have somewhat ugly code than having broken code.

> It's short responses like this and the continued reliance on arguments
> posed in a different era/landscape that compel me to reconsider my
> continued participation in the PHP community at all.

Sorry, but arguing from "do this or that or I'm quitting" does not seem
a very strong argument to me. More drama does not help to evaluate the
merits of changing the associativity of ?:. I think everybody here
values the time of the volunteers that continue to contribute to the
project, but I think keeping the discussion on the technical merits
would be better.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Ferenc Kovacs]

On Mon, Dec 15, 2014 at 8:45 PM, Zeev Suraski  wrote:
>
> > -Original Message-
> > From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
> > Behalf Of Adam Harvey
> > Sent: Monday, December 15, 2014 8:12 PM
> > To: Derick Rethans
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
> >
> > On 15 December 2014 at 08:51, Derick Rethans  wrote:
> > > Yes, I disagree. It's a time thing. Let's all work on one thing
> > > instead of *two*. Clearly you must see that there is not enough
> > > bandwidth? It will also prevent people from "oh we can get this into
> > > 5.7"
> > nonsense.
> > > It's not helpful, and it *is* fragmenting development.
> >
> > I'm just as cognisant of our time constraints as you are, but I still
> > think this
> > can work if there's a clear, written expectation (say via
> > RFC) that 5.7 is for migration related changes only, and should not
> > include
> > new feature work. If we can keep this as "5.6 + some deprecation
> > warnings",
> > I believe that can reduce the QA/development load enough to make
> > delivering it and 7.0 possible next year.
>
> 5.6 + deprecation warnings might be something we can even consider for the
> 5.6.x tree, as we get closer to release 7.0.  I think if we do that, it
> becomes more interesting since the likelihood of people upgrading to such a
> version go higher (psychologically, moving to 5.7 is a much bigger deal
> than
> upgrading from 5.6.10 to 5.6.11).




there are two advantages for having 5.7 and having those deprecated
messages in 5.7:
1, if we introduce the deprecated message in 5.6.x, some people will miss
it (for example debian jessie has 5.6.2)
2, would allow us to stabilize 5.6 instead of keep adding stuff to it
continuously .



-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

RE: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Zeev Suraski]

> -Original Message-
> From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
> Behalf Of Adam Harvey
> Sent: Monday, December 15, 2014 8:12 PM
> To: Derick Rethans
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
>
> On 15 December 2014 at 08:51, Derick Rethans  wrote:
> > Yes, I disagree. It's a time thing. Let's all work on one thing
> > instead of *two*. Clearly you must see that there is not enough
> > bandwidth? It will also prevent people from "oh we can get this into
> > 5.7"
> nonsense.
> > It's not helpful, and it *is* fragmenting development.
>
> I'm just as cognisant of our time constraints as you are, but I still
> think this
> can work if there's a clear, written expectation (say via
> RFC) that 5.7 is for migration related changes only, and should not
> include
> new feature work. If we can keep this as "5.6 + some deprecation
> warnings",
> I believe that can reduce the QA/development load enough to make
> delivering it and 7.0 possible next year.

5.6 + deprecation warnings might be something we can even consider for the
5.6.x tree, as we get closer to release 7.0.  I think if we do that, it
becomes more interesting since the likelihood of people upgrading to such a
version go higher (psychologically, moving to 5.7 is a much bigger deal than
upgrading from 5.6.10 to 5.6.11).

Zeev

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

RE: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Zeev Suraski]

> -Original Message-
> From: Adam Harvey [mailto:a...@adamharvey.name]
> Sent: Monday, December 15, 2014 8:06 PM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] On the road to PHP 5.7 , or not ?
>
> On 12 December 2014 at 23:19, Zeev Suraski  wrote:
> > 3.  Last (and probably least) - a 5.7 that breaks compatibility is
> > inconsistent with our version strategy, that suggests 5.7 should be
> > fully compatible with 5.6.
>
> Whoa — I'm not talking about breaking compatibility. I'm talking about
> generating deprecation warnings on things we know are going to break in
> PHP 7.

Ok, that's borderline breaking compatibility if we want people to actually
notice it (otherwise it'd be hidden by default settings).  But I admit
that's nitpicking, withdrawn :)

Anyway, the #1 (literally) in my email was that the OP (Julien) clearly had
a different 5.7 in mind than what you're describing.

> As I said, 5.7 wouldn't break anything, to my mind. The point is to
> provide a
> way for users to get a heads up on what things they need to be looking
> into
> to either migrate to PHP 7, or have a single code base that runs on both
> PHP
> 5 and 7, depending on their needs.
>
> The Python experience suggests that both of these cases _need_ to be
> supported, and well. Why wouldn't we — the people best placed to do so —
> provide the tooling to do that as part of the runtime?
>
> The strawman version of your position seems to be that users are going to
> just migrate to PHP 7 en masse, and that they'll be happy with their code
> breaking to tell them what to fix. I'm not sure there's any history in PHP
> or
> other languages that suggests that's really what will happen, and I think
> we're doing our users a disservice if we don't make the path to having a
> mixed 5/7 code base as easy as possible.

I don't think people will migrate to PHP 7 en-masse.  Our past experience
with major versions (and even minor ones) doesn't support this thesis -
it'll take time.  But I do think that people who decide it's worth their
while to migrate, will migrate and take the pain that it takes to make the
necessary changes.  The extra pain associated with migrating to an interim
version - that does nothing but spew warnings in the right places -and
obviously doesn't have any of the other features of 7 - doesn't seem to be a
worthwhile experience for most users.

Zeev

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

Re: [PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection

[Miloslav Hůla]

Oh, thank you both. I added info that voting will be closed next Monday.

Thank you, Milo


Dne 15.12.2014 20:14, Andrea Faulds napsal(a):

On 15 Dec 2014, at 18:08, Christoph Becker  wrote:
It seems to me that it's customary to specify the voting period *in
advance* (cf. other RFC currently in the voting phase[1]).  Not sure,
though, if it's a problem to do otherwise.

[1] 


Yes, you should specify one ahead of time. Otherwise it looks like you are only 
closing it when convenient (e.g. extra yes vote at last minute).



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

Re: [PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection

[Andrea Faulds]

> On 15 Dec 2014, at 18:08, Christoph Becker  wrote:
> 
> Miloslav Hůla:
> 
>> It is two weeks I opened the RFC voting. Even the responses are negative
>> for now, I would like to remind you to vote.
>> 
>> Because the amount of votes is low, I hope I didn't do some mistake in
>> RFC procedure.
> 
> It seems to me that it's customary to specify the voting period *in
> advance* (cf. other RFC currently in the voting phase[1]).  Not sure,
> though, if it's a problem to do otherwise.
> 
> [1] 

Yes, you should specify one ahead of time. Otherwise it looks like you are only 
closing it when convenient (e.g. extra yes vote at last minute).

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

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Rowan Collins]

Leon Sorokin wrote on 13/12/2014 22:45:

Hi guys,

I was wondering if 7.0 could be the version to fix the long-standing 
incorrect ternary associativity bug in PHP [1]. This seems especially 
worthy of reconsideration since the Null Coalesce RFC has been 
accepted and merged [2] with the correct associativity [3].


The major version change seems like the only time to get this done in 
PHP.


[1] https://bugs.php.net/bug.php?id=61915
[2] https://wiki.php.net/rfc/isset_ternary
[3] http://news.php.net/php.internals/79584

thanks,

--
Leon Sorokin



Actually, thinking further on this, I'm not sure I've ever actually been 
affected by the associativity of ?: one way or the other.


I have fallen foul of its precedence relative to concatenation, as in:

echo 'hello' . false ? ' world' : ' there' . '!';
http://3v4l.org/i7cSc

But I think this is the same in other languages, and not related to this 
bug?


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Adam Harvey]

On 15 December 2014 at 08:51, Derick Rethans  wrote:
> Yes, I disagree. It's a time thing. Let's all work on one thing instead
> of *two*. Clearly you must see that there is not enough bandwidth? It
> will also prevent people from "oh we can get this into 5.7" nonsense.
> It's not helpful, and it *is* fragmenting development.

I'm just as cognisant of our time constraints as you are, but I still
think this can work if there's a clear, written expectation (say via
RFC) that 5.7 is for migration related changes only, and should not
include new feature work. If we can keep this as "5.6 + some
deprecation warnings", I believe that can reduce the QA/development
load enough to make delivering it and 7.0 possible next year.

Adam, who apparently put his optimistic pants on this morning.

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

[PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection

[Christoph Becker]

Miloslav Hůla:

> It is two weeks I opened the RFC voting. Even the responses are negative
> for now, I would like to remind you to vote.
> 
> Because the amount of votes is low, I hope I didn't do some mistake in
> RFC procedure.

It seems to me that it's customary to specify the voting period *in
advance* (cf. other RFC currently in the voting phase[1]).  Not sure,
though, if it's a problem to do otherwise.

[1] 

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Add a new flag for json_encode

[Ferenc Kovacs]

On Mon, Dec 15, 2014 at 6:16 PM, Juan Basso  wrote:
>
> Ok guys, sorry, but I am giving up on it.
>
> I opened the PR in April and all the code necessary with technical
> implications are done and registered on the PR. I brought the topic to this
> email list in November as requested in the PR and almost 1 month after you
> guys requested me to write a RFC. I tried to create a wiki account to write
> the RFC 15 days ago[1] and I had no answer in create a simple wiki account.
>
> I have no idea how long it will take and how long the RFC will be on
> discussion, but seems the whole process will take over 1 year.
> Unfortunately I don't have patience enough for it. I guess I put my
> contribution on the project proposing the code, discussing the technical
> part and executing benchmarks. If you want to use it, use, but if you want
> to just ignore because I didn't complete all the steps fine too, just close
> the PR and this topic is automatically closed.
>
> I would like to contribute more with PHP core, but if this is the process
> to contribute with PHP, I am out. I will help other projects that give more
> attention and love for who wants to contribute and not making the person to
> worry about the bureaucratic part. Sorry.
>
> [1] http://news.php.net/php.webmaster/20312
>

Hi,

I'm sorry for the negative experience, and I agree that we did a bad job
handling this PR.

ps: I've just replied to your mail, but I can understand if you aren't
going to put more effort into getting this merged.
-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Adam Harvey]

On 12 December 2014 at 23:19, Zeev Suraski  wrote:
> 3.  Last (and probably least) - a 5.7 that breaks compatibility is
> inconsistent with our version strategy, that suggests 5.7 should be fully
> compatible with 5.6.

Whoa — I'm not talking about breaking compatibility. I'm talking about
generating deprecation warnings on things we know are going to break
in PHP 7.

Travelling backwards a point:

> 2.  My position about 5.7 that's minimally different from 5.6 and just
> 'helps migration', is that it's practically useless.  Users won't go through
> the headache of hopping through two versions, for some supposed unknown
> benefits.  PHP 7 breakage is going to be fairly localized to specific
> areas - not so much the engine changes which barely breaks anything.  So if
> 5.7 'breaks' the same areas that 7.0 does (keywords, warnings in the right
> places, etc.) - migrating to it would essentially be as painful (or
> painless) as migrating to 7.0.  In other words, no benefits to doing this
> extra step from the point of view of most users.

As I said, 5.7 wouldn't break anything, to my mind. The point is to
provide a way for users to get a heads up on what things they need to
be looking into to either migrate to PHP 7, or have a single code base
that runs on both PHP 5 and 7, depending on their needs.

The Python experience suggests that both of these cases _need_ to be
supported, and well. Why wouldn't we — the people best placed to do so
— provide the tooling to do that as part of the runtime?

The strawman version of your position seems to be that users are going
to just migrate to PHP 7 en masse, and that they'll be happy with
their code breaking to tell them what to fix. I'm not sure there's any
history in PHP or other languages that suggests that's really what
will happen, and I think we're doing our users a disservice if we
don't make the path to having a mixed 5/7 code base as easy as
possible.

Adam

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

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Robert Williams]

On Dec 14, 2014, at 23:50, Leon Sorokin  wrote:
>
> On 12/14/2014 10:45 PM, Robert Williams wrote:
>
>> I strongly suspect far more code would be *fixed* if the ternary operator 
>> were changed to match what other languages do.
>
> If you have 'incorrectly' functioning code today that results in passing
> unit tests and a correctly functioning business. Then a sudden change to
> the behavior of this code would necessarily result in failing unit tests
> and an incorrectly functioning business.

What world is this that you live in where every line of code that’s written is 
fully unit-tested, where functional bugs in large, highly complex applications 
are both obvious and immediately apparent? In my world, I’ve inherited millions 
of lines of legacy code written seemingly to defy the possibility of unit 
testing, where there are large chunks of code that may run once every several 
years, and where many types of logic bugs are simply undetectable unless a team 
of auditors on the business side is double-checking every result of the code. 
Sure, I also have a million or two lines of newer code that is heavily 
unit-tested, but even that code has bugs.

Given that we have this bug to begin with (and yes, it’s a bug), as well as 
many of the others that have worked their way into the PHP code base, it 
strikes me that PHP itself is written in my world, not yours. Hey, reality 
bites.

Also, code that is thoroughly unit-tested is not the code we need to worry 
about for the very reasons you espouse. If the ternary behavior is changed, the 
one or two bugs that may be introduced in every several hundred K LOC will 
become immediately apparent on first test-run and probably be fixed in 30 
minutes or less. It’s the crappy code that we have to worry about, the code 
that’s broken and no one even knows about it. In these cases, I maintain, 
fixing ternary would only improve the code’s functioning.

-Bob

--
Bob Williams
SVP, Software Development
Newtek Business Services, Inc.
“The Small Business Authority”
http://www.thesba.com/



Notice: This communication, including attachments, may contain information that 
is confidential. It constitutes non-public information intended to be conveyed 
only to the designated recipient(s). If the reader or recipient of this 
communication is not the intended recipient, an employee or agent of the 
intended recipient who is responsible for delivering it to the intended 
recipient, or if you believe that you have received this communication in 
error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments without reading or saving them in any 
manner. The unauthorized use, dissemination, distribution, or reproduction of 
this e-mail, including attachments, is prohibited and may be unlawful. If you 
have received this email in error, please notify us immediately by e-mail or 
telephone and delete the e-mail and the attachments (if any).

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Rowan Collins]

Pierre Joye wrote on 15/12/2014 17:39:

I hate to say that but if we stick to rules, this rfc and its result are
> >totally invalid and should be canceled.

>
>What a bonkers statement. Just because you don't agree it's not
>"totally invalid". I think 34 vs 2 is a pretty solid argument for
>sticking to it.

Aller php7 related RFCs from there are  invalid if we stick to the rules.
The author asked to respect rules while systematically breaking them. And
that's my point here.


Can you succinctly, without any personal attacks, explain which rules 
this RFC broke?


Thanks,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Pierre Joye]

On Dec 15, 2014 11:53 PM, "Derick Rethans"  wrote:
>
> On Sat, 13 Dec 2014, Pierre Joye wrote:
>
> > On Dec 12, 2014 9:34 PM, "Derick Rethans"  wrote:
> > >
> > > On Fri, 12 Dec 2014, Julien Pauli wrote:
> > >
> > > > So the main question is : *What version will we release next year ?*
> > > >
> > > > Will we have a PHP 5.7, or jump directly to a 7.0 ?
> > > >
> > > > Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
> > > > least one year later.
> > >
> > > We have accepted the timeline for 7, so we need to stick to that:
> > > https://wiki.php.net/rfc/php7timeline#vote
> > >
> >
> > I hate to say that but if we stick to rules, this rfc and its result are
> > totally invalid and should be canceled.
>
> What a bonkers statement. Just because you don't agree it's not
> "totally invalid". I think 34 vs 2 is a pretty solid argument for
> sticking to it.

Aller php7 related RFCs from there are  invalid if we stick to the rules.
The author asked to respect rules while systematically breaking them. And
that's my point here.

People voting massively yes because " oh it will not happen if we don't say
yes now" is only bad. For that last one, even the author admit that we may
not make it as described.

I may propose a counter rfc or just for 5.7, did not make my mind yet. Why
should I make a php7 more complete rfc? Because we agreed to make one
together to propose actual choices. I was respectful enough to wait on the
other author until he was ready. Nice move.

So please, before you go up your horse telling me that my arguments are
bad, get your facts straight, thanks.

Cheers,
Pierre

Re: [PHP-DEV] Add a new flag for json_encode

[Juan Basso]

Ok guys, sorry, but I am giving up on it.

I opened the PR in April and all the code necessary with technical
implications are done and registered on the PR. I brought the topic to this
email list in November as requested in the PR and almost 1 month after you
guys requested me to write a RFC. I tried to create a wiki account to write
the RFC 15 days ago[1] and I had no answer in create a simple wiki account.

I have no idea how long it will take and how long the RFC will be on
discussion, but seems the whole process will take over 1 year.
Unfortunately I don't have patience enough for it. I guess I put my
contribution on the project proposing the code, discussing the technical
part and executing benchmarks. If you want to use it, use, but if you want
to just ignore because I didn't complete all the steps fine too, just close
the PR and this topic is automatically closed.

I would like to contribute more with PHP core, but if this is the process
to contribute with PHP, I am out. I will help other projects that give more
attention and love for who wants to contribute and not making the person to
worry about the bureaucratic part. Sorry.

[1] http://news.php.net/php.webmaster/20312


Juan Basso

On Sun, Nov 30, 2014 at 11:58 PM, Juan Basso  wrote:

> I see. I thought it was some sort of simplified RFC. :)
>
> Ok, I will create a RFC regarding it.
>
> On Sun, Nov 30, 2014 at 8:49 PM, Andrea Faulds  wrote:
>
>>
>> > On 1 Dec 2014, at 01:48, Juan Basso  wrote:
>> >
>> > What is ofc? I never heard about it before. Do I need to do something?
>>
>> “ofc” is just an abbreviation for “of course”.
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
>>
>>
>>
>

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Derick Rethans]

On Sun, 14 Dec 2014, George Bond wrote:

> If you wanted an upgrade path that was not Evil (in the sense of not 
> introducing subtle and hard-to-diagnose bugs), could you not change 
> the operator to be *un*associative in PHP7?  That would effectively 
> just make concrete the discouragement/deprecation that's already in 
> the documentation, and would produce irritating but very visible 
> errors for anyone still actually using this functionality, as well as 
> making them alter their code in a forward-compatible way.  Then if you 
> want to think really long term, plan to implement the 'correct' 
> associativity in the *next* major version.

As long as this unassociativity turns it into a hard syntax error (ie, 
"php -l" will catch it out), I am not against this.

cheers,
Derick

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Derick Rethans]

On Sat, 13 Dec 2014, Pierre Joye wrote:

> On Dec 12, 2014 9:34 PM, "Derick Rethans"  wrote:
> >
> > On Fri, 12 Dec 2014, Julien Pauli wrote:
> >
> > > So the main question is : *What version will we release next year ?*
> > >
> > > Will we have a PHP 5.7, or jump directly to a 7.0 ?
> > >
> > > Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at
> > > least one year later.
> >
> > We have accepted the timeline for 7, so we need to stick to that:
> > https://wiki.php.net/rfc/php7timeline#vote
> >
> 
> I hate to say that but if we stick to rules, this rfc and its result are
> totally invalid and should be canceled.

What a bonkers statement. Just because you don't agree it's not 
"totally invalid". I think 34 vs 2 is a pretty solid argument for 
sticking to it.

cheers,
Derick

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

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

[Derick Rethans]

On Fri, 12 Dec 2014, Ferenc Kovacs wrote:

> On Fri, Dec 12, 2014 at 3:34 PM, Derick Rethans  wrote:
> >
> > On Fri, 12 Dec 2014, Julien Pauli wrote:
> >
> > > So the main question is : *What version will we release next year 
> > > ?*
> > >
> > > Will we have a PHP 5.7, or jump directly to a 7.0 ?
> > >
> > > Don't forget, that if we go for a 5.7 , then we won't have a 7.0 
> > > at least one year later.
> >
> > We have accepted the timeline for 7, so we need to stick to that: 
> > https://wiki.php.net/rfc/php7timeline#vote
> >
> > So that means no 5.7.
>
> This rfc was specific to php7, and while you are right that with that 
> we do have an approved timelime for php7, but this doesn't say 
> anything about 5.7 (and as far as I'm concerned, it was an intentional 
> choice from Zeev not just something he forgot to include).
>
> Maybe it would be worthwile for you to repeat your arguments or simply 
> link them, as I do remember that you are supporting the idea of not 
> having any other release minor release until php7 is out of the door 
> so the development efforts are not fragmented (which as I mentioned in 
> my previous mail I feell it would be only a shift from 5.6.x to 5.7.0 
> and not fragmanting the php7 development, but you seem to disagree).

Yes, I disagree. It's a time thing. Let's all work on one thing instead 
of *two*. Clearly you must see that there is not enough bandwidth? It 
will also prevent people from "oh we can get this into 5.7" nonsense. 
It's not helpful, and it *is* fragmenting development.

cheers,
Derick

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

[PHP-DEV] Re: [VOTE][RFC] Access to aliases definition by reflection

[Miloslav Hůla]

Hi Internals,

It is two weeks I opened the RFC voting. Even the responses are negative 
for now, I would like to remind you to vote.


Because the amount of votes is low, I hope I didn't do some mistake in 
RFC procedure.


Thank you, Milo


Dne 26.11.2014 10:48, Miloslav Hůla napsal(a):

Good morning internals,

after several weeks, I'm opening voting process for the RFC
https://wiki.php.net/rfc/aliases_by_reflection.

Thank you, Milo



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