Hey,
On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote:
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
On Tue, Dec 16, 2014 at 9:00 AM, Andrea Faulds a...@ajf.me wrote:
Hey,
On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote:
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
On Tue, Dec 16, 2014 at 12:32 AM, Johannes Schlüter johan...@schlueters.de
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
On Mon, Dec 15, 2014 at 8:56 AM, Derick Rethans der...@php.net wrote:
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?
Hi!
I'd like to initiate a vote on objects as keys RFC:
https://wiki.php.net/rfc/objkey
I know this is a holiday season but it was extensively discussed and I
think most people already formed their opinions. I've put the voting
period as 3 weeks to have some time for people to vote even with the
Hi!
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.
Thanks for your work! I think it may be good to make it a pull, since
it'd be easier to
On 16/12/14 07:29, Levi Morrison wrote:
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
Hi!
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 you do it in a professional way, with properly randomized samples,
controlled statistics, etc. Putting a form on the internet and counting
people
Hi!
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
Hi all,
On Tue, Dec 16, 2014 at 6:17 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
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 you do it in a professional way, with properly randomized
On Tue, Dec 16, 2014 at 06:48:14PM +0900, Yasuo Ohgaki wrote:
Instead of polling people, how about provide a compatibility check script?
This would be easy with tokenizer, I suppose.
+1
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
On 16.12.14 09:34, Stanislav Malyshev wrote:
I'd like to initiate a vote on objects as keys RFC:
https://wiki.php.net/rfc/objkey
Am I right this only covers the transformation into the array. Once it's
in it's essential a array compatible key entity (string/integer) so when
you var_dump($array)
Hi Markus,
On 16 Dec 2014, at 10:31, Markus Fischer mar...@fischer.name wrote:
On 16.12.14 09:34, Stanislav Malyshev wrote:
I'd like to initiate a vote on objects as keys RFC:
https://wiki.php.net/rfc/objkey
Am I right this only covers the transformation into the array. Once it's
in
On 16/12/2014 08:55, Andrea Faulds wrote:
Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation
notices? I’m unaware of any.
I've tried to search the ML for such list of RFCs:
https://wiki.php.net/rfc/gc_fn_pointer
https://wiki.php.net/rfc/secure_unserialize (also 5.6 if
Hey Matteo,
On 16 Dec 2014, at 10:52, Matteo Beccati p...@beccati.com wrote:
On 16/12/2014 08:55, Andrea Faulds wrote:
Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation
notices? I’m unaware of any.
I've tried to search the ML for such list of RFCs:
On 16 Dec 2014, at 10:52, Andrea Faulds a...@ajf.me wrote:
Exactly. If I were to do this:
?php
class Foo {
public $foo;
function __construct($foo) {
$this-foo = $foo;
}
function __toKey() {
return $this-foo;
}
}
Hey Stas,
On 16 Dec 2014, at 09:25, Stanislav Malyshev smalys...@gmail.com wrote:
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
Patrick Schaaf in php.internals (Mon, 15 Dec 2014 21:36:33 +0100):
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
Hi Andrea,
On 16/12/2014 12:10, Andrea Faulds wrote:
It'd be nice to describe what we have now for 5.7 - i.e. which
deprecation messages and other warnings are on the agenda? Doesn't have
to be the exclusive list but at least to give the idea what we're
talking about.
At the moment, there’s
On 16/12/2014 12:03, Andrea Faulds wrote:
I wrote the Closure::call() and intdiv() RFCs. Truth be told, they
both targeted master, not a specific PHP version. master has become
PHP 7, so whatever the wording of them said, they really target PHP 7
now. They were written back before the whole PHP
Hey Matteo,
On 16 Dec 2014, at 11:29, Matteo Beccati p...@beccati.com wrote:
This is what I meant when I previously mentioned seeing RFCs targeting 5.7. I
understand what you say and I do wholeheartedly agree with you.
However if one would have to strictly follow what has been voted,
Hi,
All I can say is that the lack of this feature is one of the main reasons why
Doctrine doesn't fully work with composite keys.
With this enhancement it would now become possible to implement a proper
IdentityMap.
[]s,
On Dec 16, 2014, at 9:05 AM, Andrea Faulds a...@ajf.me wrote:
On 16
On 16/12/2014 11:52, Andrea Faulds wrote:
This is the main problem with the RFC: magic, implicit, one-way data
loss (object to integer/string).
I was previously in favour of this, but it’d prevent actual indexing
by objects in future, and I can’t think of any use cases which aren’t
better
Hi Guilherme,
On 16/12/2014 12:34, Guilherme Blanco wrote:
Hi,
All I can say is that the lack of this feature is one of the main reasons why
Doctrine doesn't fully work with composite keys.
With this enhancement it would now become possible to implement a proper
IdentityMap.
Are you sure
Am 16.12.2014 12:36 schrieb Matteo Beccati p...@beccati.com:
On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
by objects in future, and I can’t think of any use cases which aren’t
better solved by explicitly converting to a
Patrick Schaaf wrote on 16/12/2014 11:46:
Am 16.12.2014 12:36 schrieb Matteo Beccati p...@beccati.com:
On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
by objects in future, and I can’t think of any use cases which aren’t
better
Hi,
Le 16 déc. 2014 13:45, Rowan Collins rowan.coll...@gmail.com a écrit :
Patrick Schaaf wrote on 16/12/2014 11:46:
Am 16.12.2014 12:36 schrieb Matteo Beccati p...@beccati.com:
On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Tuesday, December 16, 2014 10:00 AM
To: Ferenc Kovacs
Cc: Matteo Beccati; Xinchen Hui; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
Hey,
On 16 Dec 2014, at 07:58, Ferenc Kovacs tyr...@gmail.com wrote:
We
-Original Message-
From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On
Behalf Of Levi Morrison
Sent: Tuesday, December 16, 2014 9:29 AM
To: Xinchen Hui
Cc: Andrea Faulds; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
There has been some debate about whether to
On Tue, Dec 16, 2014 at 10:25 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
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
On Tue, Dec 16, 2014 at 12:03 PM, Andrea Faulds a...@ajf.me wrote:
Hey Matteo,
On 16 Dec 2014, at 10:52, Matteo Beccati p...@beccati.com wrote:
On 16/12/2014 08:55, Andrea Faulds wrote:
Could you tell me which RFCs targeted 5.7 and didn’t just add
deprecation notices? I’m unaware of
On Tue, Dec 16, 2014 at 12:33 PM, Andrea Faulds a...@ajf.me wrote:
Hey Matteo,
On 16 Dec 2014, at 11:29, Matteo Beccati p...@beccati.com wrote:
This is what I meant when I previously mentioned seeing RFCs targeting
5.7. I understand what you say and I do wholeheartedly agree with you.
On Tue, Dec 16, 2014 at 4:23 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On
Behalf Of Levi Morrison
Sent: Tuesday, December 16, 2014 9:29 AM
To: Xinchen Hui
Cc: Andrea Faulds; PHP Internals
Subject:
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
I was initially very much in favour of a 5.7 release, but given the current
lack of big BC breaks I'm not so sure. I can even run a dinosaur like Revive
on PHP7!
If the list of BC breaks grows (e.g. PHP4 constructors -- which I seriously
hope doesn't pass -- or other big / evil ones), then I
as you mentioned distros lock in to a specific micro version, so if we
introduce this deprecated messages in random micro version, we make it less
likely for the users to stumble upon those deprecated messages and it will
be also harder for us to communicate the upgrade path:
compare:
okay, you
On Tue, Dec 16, 2014 at 5:44 PM, Zeev Suraski z...@zend.com wrote:
as you mentioned distros lock in to a specific micro version, so if we
introduce this deprecated messages in random micro version, we make it less
likely for the users to stumble upon those deprecated messages and it will
be
On Dec 16, 2014 9:10 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Tuesday, December 16, 2014 10:00 AM
To: Ferenc Kovacs
Cc: Matteo Beccati; Xinchen Hui; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
Hey,
On Dec 16, 2014 10:23 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On
Behalf Of Levi Morrison
Sent: Tuesday, December 16, 2014 9:29 AM
To: Xinchen Hui
Cc: Andrea Faulds; PHP Internals
Subject: Re:
Hi!
I was previously in favour of this, but it’d prevent actual indexing
No, of course it won't - if we ever introduce indexing objects (which
probably will require rewrite of the HashTable, any takers?) it would be
very easy to index any object that does not implement __hash without any
BC
On Tue, Dec 16, 2014 at 12:49 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
Thanks for your work! I think it may be good to make it a pull, since
it'd be easier to comment on that (and also Travis can say its word of
course :)
Can do!
https://github.com/php/php-src/pull/961
It says some
Hi!
I've tried to search the ML for such list of RFCs:
https://wiki.php.net/rfc/gc_fn_pointer
https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree)
https://wiki.php.net/rfc/closure_apply
https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6)
On 16 December 2014 18:14:27 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I was previously in favour of this, but it’d prevent actual indexing
No, of course it won't - if we ever introduce indexing objects (which
probably will require rewrite of the HashTable, any takers?) it would
Hi!
Explicit conversion is trivial, just call whatever method you like.
Sure, you can't write (int)$obj, but $obj-toInt() is just as
expressive.
Exactly the same applies to __toString and whole ArrayAccess, yet we
still have them. Avoiding boilerplate code helps. Especially if
boilterplate
On 16 December 2014 16:44:59 GMT, Zeev Suraski z...@zend.com wrote:
as you mentioned distros lock in to a specific micro version, so if we
introduce this deprecated messages in random micro version, we make it
less
likely for the users to stumble upon those deprecated messages and it
will
be also
On 16 December 2014 at 10:38, Stanislav Malyshev smalys...@gmail.com wrote:
I've tried to search the ML for such list of RFCs:
https://wiki.php.net/rfc/gc_fn_pointer
https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree)
https://wiki.php.net/rfc/closure_apply
Hi list,
I think having a minor PHP version for the only sake of adding E_DEPRECATED
is kind of pointless to be honest. Historically, PHP (or other languages
for the matter, I'm thinking of python) minor versions have brought new
features. Adding notices is not a reason for a new version imho.
On 16 December 2014 18:50:06 GMT, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Explicit conversion is trivial, just call whatever method you like.
Sure, you can't write (int)$obj, but $obj-toInt() is just as
expressive.
Exactly the same applies to __toString and whole ArrayAccess, yet
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com
wrote:
Hi list,
I think having a minor PHP version for the only sake of adding E_DEPRECATED
is kind of pointless to be honest. Historically, PHP (or other languages
for the matter, I'm thinking of python) minor versions
Hey Florian,
On 16 Dec 2014, at 19:55, Florian Margaine flor...@margaine.com wrote:
Hi list,
I think having a minor PHP version for the only sake of adding E_DEPRECATED
is kind of pointless to be honest. Historically, PHP (or other languages
for the matter, I'm thinking of python) minor
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com
wrote:
Hi list,
I think having a minor PHP version for the only sake of adding E_DEPRECATED
is kind of pointless to be honest. Historically, PHP (or other languages
for the matter, I'm thinking of python) minor versions
-Original Message-
From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
Julien Pauli
Sent: Tuesday, December 16, 2014 11:00 PM
To: Florian Margaine
Cc: Rowan Collins; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
- We cannot patch 5.6 to add any
On 16 December 2014 at 13:18, Andrea Faulds a...@ajf.me wrote:
Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a
year sounds like a better solution. If others agree, I might withdraw this
RFC.
I disagree. 2to3 wasn't a success in the Python world — in the end,
the
-Original Message-
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Tuesday, December 16, 2014 11:53 PM
To: Florian Margaine
Cc: Rowan Collins; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
please be aware the not everybody agrees on the no new features rule, but
from as I
On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote:
- We cannot patch 5.6 to add any Warnings-of-any-kind (stable release,
under release process that forbids that)
What part of the release process forbids that?
None, but I'd still advocate releasing a new minor because there's
On Tue, Dec 16, 2014 at 9:59 PM, Julien Pauli jpa...@php.net wrote:
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine flor...@margaine.com
wrote:
Hi list,
I think having a minor PHP version for the only sake of adding
E_DEPRECATED
is kind of pointless to be honest. Historically, PHP
-Original Message-
From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Wednesday, December 17, 2014 12:10 AM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote:
On 16 December 2014 at 14:19, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Wednesday, December 17, 2014 12:10 AM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
- Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new
features cancels point number one
What else ?
Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing
major compatibility breakages in 7.0 (at least not at this time), to the
level that
On Tue, Dec 16, 2014 at 11:08 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Tuesday, December 16, 2014 11:53 PM
To: Florian Margaine
Cc: Rowan Collins; PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7
please
On Dec 17, 2014 4:19 AM, Andrea Faulds a...@ajf.me wrote:
Hey Florian,
On 16 Dec 2014, at 19:55, Florian Margaine flor...@margaine.com wrote:
Hi list,
I think having a minor PHP version for the only sake of adding
E_DEPRECATED
is kind of pointless to be honest. Historically, PHP (or
On Wed, Dec 17, 2014 at 10:45 AM, Andrea Faulds a...@ajf.me wrote:
Hi Pierre,
On 16 Dec 2014, at 23:42, Pierre Joye pierre@gmail.com wrote:
On Dec 17, 2014 4:19 AM, Andrea Faulds a...@ajf.me wrote:
Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support
by a year
guilhermebla...@gmail.com wrote:
On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati p...@beccati.com
wrote:
Are you sure you haven't misinterpreted the RFC?
I did not. You may think I mentioned IdentityMap as entity map, but I'm
talking about entityPersister mapping or resultPointers
Hi!
AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
I'm not sure what you mean by some sugar only. It introduces the
capability of using objects in array key context, which was not
available until now.
possible to have object hashes without __hash(), by introducing a
Hi Stas,
On 17 Dec 2014, at 01:32, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
I'm not sure what you mean by some sugar only. It introduces the
capability of using objects in array key context, which was not
Stanislav Malyshev wrote:
AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
I'm not sure what you mean by some sugar only. It introduces the
capability of using objects in array key context, which was not
available until now.
Yes, but it is already possible to call an
Hi!
Yes, but it is already possible to call an object's method in array key
context, so in combination with an appropriate interface the same can be
accomplished.
No, it's not possible. It is possible to call object method in an
expression, and then use the result of the expression as an
67 matches
Mail list logo
