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 ar
Hi!
>> On 17 Dec 2014, at 01:32, Stanislav Malyshev
>> 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 ca
Hi Stas,
> On 17 Dec 2014, at 01:32, Stanislav Malyshev 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
> available
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
guilhermebla...@gmail.com wrote:
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
> 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 consumptions tha
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
wrote: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 bec
On Wed, Dec 17, 2014 at 10:45 AM, Andrea Faulds wrote:
> Hi Pierre,
>
>> On 16 Dec 2014, at 23:42, Pierre Joye wrote:
>>
>>
>> On Dec 17, 2014 4:19 AM, "Andrea Faulds" wrote:
>> >
>> > Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support
>> > by a year sounds like a better s
Hi Pierre,
> On 16 Dec 2014, at 23:42, Pierre Joye wrote:
>
>
> On Dec 17, 2014 4:19 AM, "Andrea Faulds" 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.
> >
>
On Dec 17, 2014 4:19 AM, "Andrea Faulds" wrote:
>
> Hey Florian,
>
> > On 16 Dec 2014, at 19:55, Florian Margaine 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 language
> From: a...@adamharvey.name [mailto:a...@adamharvey.name] On
> Behalf Of Adam Harvey
> Sent: Wednesday, December 17, 2014 12:29 AM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] [RFC] PHP 5.7
>
> I think it's actually more likely that people will upgrade to a new minor
> than a
>
On Tue, Dec 16, 2014 at 11:08 PM, Zeev Suraski 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
> >
> > plea
>
>
> > - 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
On 16 December 2014 at 14:19, Zeev Suraski 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
>>
> -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 wrote:
> >>
On Tue, Dec 16, 2014 at 9:59 PM, Julien Pauli wrote:
>
> On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine
> 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
>
On 16 December 2014 at 14:00, Zeev Suraski 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
plenty of a
> -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
> f
On 16 December 2014 at 13:18, Andrea Faulds 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 only mig
> -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 War
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine
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 have brought new
Hey Florian,
> On 16 Dec 2014, at 19:55, Florian Margaine 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 have
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine
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 have brought new
On 16 December 2014 18:50:06 GMT, Stanislav Malyshev
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 we
>still
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.
If
On 16 December 2014 at 10:38, Stanislav Malyshev 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
>> https://wiki.php.net/rfc/pa
On 16 December 2014 16:44:59 GMT, Zeev Suraski 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 harder f
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 18:14:27 GMT, Stanislav Malyshev
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
>be
>very eas
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)
> https://wiki.ph
On Tue, Dec 16, 2014 at 12:49 AM, Stanislav Malyshev
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 methods" but I
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 pr
On Dec 16, 2014 10:23 PM, "Zeev Suraski" 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:
On Dec 16, 2014 9:10 PM, "Zeev Suraski" 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 Tue, Dec 16, 2014 at 5:44 PM, Zeev Suraski 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 harde
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 o
> 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), t
>> >> 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
On Tue, Dec 16, 2014 at 4:23 PM, Zeev Suraski 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:
On Tue, Dec 16, 2014 at 12:33 PM, Andrea Faulds wrote:
>
> Hey Matteo,
>
> > On 16 Dec 2014, at 11:29, Matteo Beccati 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 o
On Tue, Dec 16, 2014 at 12:03 PM, Andrea Faulds wrote:
>
> Hey Matteo,
>
> > On 16 Dec 2014, at 10:52, Matteo Beccati 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
On Tue, Dec 16, 2014 at 10:25 AM, Stanislav Malyshev
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
> > features whats
> -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 w
> -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 wrote:
> >
> > We a
Hi,
Le 16 déc. 2014 13:45, "Rowan Collins" a écrit :
>
> Patrick Schaaf wrote on 16/12/2014 11:46:
>
>> Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
>>>
>>> On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
by objects i
Patrick Schaaf wrote on 16/12/2014 11:46:
Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
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 explicit
Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
>
> 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 string/inte
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 yo
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 solved
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 wrote:
>>
>> On 16 Dec 201
Hey Matteo,
> On 16 Dec 2014, at 11:29, Matteo Beccati 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, such
> featur
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 7
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 Le
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 b
Hey Stas,
> On 16 Dec 2014, at 09:25, Stanislav Malyshev 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.
>
> On 16 Dec 2014, at 10:52, Andrea Faulds wrote:
>
> Exactly. If I were to do this:
>
>class Foo {
>public $foo;
>function __construct($foo) {
>$this->foo = $foo;
>}
>function __toKey() {
>return $this->foo;
>}
>}
>
Hey Matteo,
> On 16 Dec 2014, at 10:52, Matteo Beccati 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:
>
> https://wiki.php.
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 R
Hi Markus,
> On 16 Dec 2014, at 10:31, Markus Fischer 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 it's essent
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($arr
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.
+
Hi all,
On Tue, Dec 16, 2014 at 6:17 PM, Stanislav Malyshev
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 samples,
> contro
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 an
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
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
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
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 th
On Mon, Dec 15, 2014 at 8:56 AM, Derick Rethans 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? That would
On Tue, Dec 16, 2014 at 12:32 AM, 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 (
On Tue, Dec 16, 2014 at 9:00 AM, Andrea Faulds wrote:
>
> Hey,
>
> > On 16 Dec 2014, at 07:58, Ferenc Kovacs 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
Hey,
> On 16 Dec 2014, at 07:58, Ferenc Kovacs 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 minor version
71 matches
Mail list logo
