> -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:
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
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 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 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
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,
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
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
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
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
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
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
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
13 matches
Mail list logo
