Results for project PHP master, build date 2017-02-14 20:28:33-08:00
commit: 2ed4723
previous commit:00e5ea7
revision date: 2017-02-14 14:16:54+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Tue, Feb 14, 2017 at 10:20 PM, Levi Morrison wrote:
> On Tue, Feb 14, 2017 at 2:14 PM, Levi Morrison wrote:
> > On Tue, Feb 14, 2017 at 11:55 AM, Dan Ackroyd
> wrote:
> >> Hi Levi,
> >>
> >> On 24 November 2016 at 08:58, Dan Ackroyd
> wrote:
> >>> Hi Levi,
> >>>
> >>> On 23 November 2016 at
Hi!
> While that's an understandable argument, what happens if we flip it? Is
> there any benefit to keeping it?
Yes. Not having to change it :) Please note that the barrier for
changing something, especially in a mature software product like PHP,
especially in a core language, is way way higher
2017-02-15 21:25 GMT+01:00 Michał Brzuchalski :
> Assumming they would be closer to immutable objects they may have some
> usefull... I was gonna say methods but the term doesn't fit to enums.
> But using one of my favourite userland implementation such as `esky\enum`
> package there are ways to c
Assumming they would be closer to immutable objects they may have some
usefull... I was gonna say methods but the term doesn't fit to enums.
But using one of my favourite userland implementation such as `esky\enum`
package there are ways to create enumeration from value or from name.
Those methods
In the light of this, maybe enums (assuming this feature comes first)
should be implemented as immutable objects rather than values?
Type-checking for enums would be important, so in PHP terms, an enum
"instance" would likely be closer to an object than a value in nature
anyway.
The way I look at
Hi,
On Wed, Feb 15, 2017 at 8:35 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > I can't speak for others, but for me, it's simply because there's no
> > reason to do it (remove it), while there may/might be a reason to
> > keep it going forward. Keeping it comes at zero cost, and if we ever
>
> Same
Hi!
> I can't speak for others, but for me, it's simply because there's no
> reason to do it (remove it), while there may/might be a reason to
> keep it going forward. Keeping it comes at zero cost, and if we ever
Same here. I just don't see what is improved by this removal. To me,
it's just dis
Hi internals,
I've prepared a PR (https://github.com/php/php-src/pull/2383) that would
change the current behavior of arrays when the first index is a negative
integer.
The main goal is to make the result of array_fill more in line with what
you would expect if the start_index is a negative integ
On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker
wrote:
> On 15.02.2017 at 13:52, Zeev Suraski wrote:
>
> >> -Original Message-
> >> From: Dan Ackroyd [mailto:dan...@basereality.com]
> >> Sent: Tuesday, February 14, 2017 8:22 PM
> >> To: Pedro Magalhães
> >> Cc: internals@lists.php.n
Hi Marco,
Marco Pivetta wrote:
Since the engine is clueless about types until autoloading happens, this is
easily solvable by providing a marker syntax for non-object hints. For
instance `function foo() : enym:MyEnum {}`
If we're going to do prefixes for non-classes, we might as well copy C
On 15.02.2017 at 13:52, Zeev Suraski wrote:
>> -Original Message-
>> From: Dan Ackroyd [mailto:dan...@basereality.com]
>> Sent: Tuesday, February 14, 2017 8:22 PM
>> To: Pedro Magalhães
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
>>
>> I
> -Original Message-
> From: Dan Ackroyd [mailto:dan...@basereality.com]
> Sent: Tuesday, February 14, 2017 8:22 PM
> To: Pedro Magalhães
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation
>
> On 3 February 2017 at 12:47, Pedro Magalhães wrote:
13 matches
Mail list logo
