Hi,
well... what I wanted to have a look at a year ago, was too many false
positive "mirror broken" messages going through, and as far as I know
that has gotten a lot better over the year already.
Additionally my day job tends to eat more time nowadays than anticipated...
So, thanks for asking,
@Larry,
I see your point, but when I said 'identity', I was thinking about
referential identity, not wether that object has identity in the user
application.
Cheers
On Nov 19, 2016 7:15 PM, "Larry Garfield" wrote:
> I'm not Paul, but...
>
> If you have a data storage system using CRAP (Create R
> -Original Message-
> From: Joe Watkins [mailto:pthre...@pthreads.org]
> Sent: Saturday, November 19, 2016 6:11 AM
> To: Pierre Joye
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
>
> Morning Pierre,
>
> That's not what the rules say.
>
> There will be a one we
2016-11-19 19:18 GMT+01:00 Larry Garfield :
> On 11/17/2016 10:12 AM, Niklas Keller wrote:
>
>> No, what Craig is proposing is a type hint that covers both the existing
>>> Countable interface and primitives which are naturally countable.
>>>
>>> If the union types RFC had passed, you'd be able to
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of Kalle
> Sommer Nielsen
> Sent: Thursday, November 17, 2016 8:46 PM
> To: Joe Watkins
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
>
> 2016-11-17 19:22 GMT+01:00 Joe Watk
Afternoon Zeev,
It first seemed like a very simple question to abolish 50%+1 votes, it
quickly become apparent that this is not viable in any sense.
Maybe I should have spotted that it wasn't sensible, maybe Pierre did and
thought I was crazy, maybe Pierre thought I had spotted it but didn't care
Afternoon Zeev,
I am not sure how much of the voting RFC I want to reform right now. I am
responding to specific problems that seem to be best fixed just by raising
the acceptance criteria. I do realize that these issues are difficult to
tease apart however, so intend to at least try to suggest re
VCS Account Rejected: bof rejected by kalle /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Otherwise - it's a simple majority (>50%, or even just the option that got
> the most votes in case of a 3-way or 4-way vote).
>
There are better options for choices of 3 or more than the most votes
system and I strongly recommend that they be used. Allow me to present an
example.
Suppose we nee
> if you've hired developers that care more about trends than your
application then you've hired the wrong developers.
A consistent, complete type-system is not a "trend".
In my experience, good developers notice things like inconsistency - and
they generally do not like it.
I am personally *not
On 20/11/2016 16:24, Rasmus Schultz wrote:
A consistent, complete type-system is not a "trend".
[...]
Anyways, glad to hear Bob Weinland has been working on typed references and
the RFC is not dead :-)
Just to reiterate, I don't agree that these two sentiments go together:
a consistent type
Hey Internals,
Sorry if this isn't the correct thing to do, I was just hoping to raise
some awareness for a PR I opened last year:
https://github.com/php/php-src/pull/1280
It's a very simple and small addition, is it possible get it merged for
7.2, or do I need to raise an RFC for it?
Thanks,
Cr
Reading through the RFC and the replies, I'm confused about this question.
Why would the comparison operators work any differently on immutable
objects?
If these were value objects, the question would make sense, but it doesn't
sound like that's what you're proposing?
With regards to the feature
On 19/11/2016 23:05, Kalle Sommer Nielsen wrote:
2016-11-19 22:56 GMT+01:00 Rowan Collins :
Again, you're looking at version numbers as primarily a branding thing
("something awesome") rather than a technical thing ("something that breaks
compatibility").
Yes because that has been our past mode
On Fri, 18 Nov 2016, Nikita Popov wrote:
> Hi internals!
>
> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
> due to time constraints. Now I'd like to propose an extended version for
> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
> performance.
>
>
On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
> __autoload is one of group (2). I think this is used a lot, and would
> *not* want to deprecate this until PHP 8.
Agreed, I still think this is used widely, it would be fine to have it
throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgra
On 20/11/2016 22:50, Daniel Morris wrote:
On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
>__autoload is one of group (2). I think this is used a lot, and would
>*not* want to deprecate this until PHP 8.
Agreed, I still think this is used widely, it would be fine to have it
throw an E_
On 11/20/2016 02:32 PM, Rowan Collins wrote:
I'm not sure what you mean by "political". The big challenge which comes
up again and again, is that take up of new versions of PHP is low. You
can blame the users for that if you like, but the reality is there's no
point rushing your shiny feature i
18 matches
Mail list logo
