Is "value" or "immutable" going to become a new reserved word? Ain't we
going to have some BC breaks because of that? If so, then "value" is going
to bring more BC breaks then "immutable".
On Sun, Feb 25, 2018 at 8:02 PM Paul Jones wrote:
>
>
> > On Feb 25, 2018, at 12:59, Silvio Marijić
> wrot
Yes, I've also took that into consideration when choosing keyword.
On Feb 26, 2018 11:35 AM, "Crocodile" wrote:
> Is "value" or "immutable" going to become a new reserved word? Ain't we
> going to have some BC breaks because of that? If so, then "value" is going
> to bring more BC breaks then "i
Currently the build is failing in some parts of the codebase that are
obviously affected in some way.
I ran valgrind for couple of failing tests and I got numerous reports about
memory leaks and conditional jumps over uninitialized values.
Not sure what is the reason for that, I had merge conflict
On Tue, Feb 13, 2018 at 9:03 PM, Pedro Magalhães wrote:
> Hi internals,
>
> I want to bring up this RFC once again given that now seems to be the right
> timing for it. I have previously canceled the vote when I initially
> proposed this to land on 7.2 which was seen as too big of a BC for a mino
Hello,
my thoughts.
For me personally the proposed feature would not be very useful.
i like immutable objects. But for me the pattern of choice is private
properties + constructor + optional "wither" methods.
The "wither" methods create a clone of the object, then set a property
value on the clone
Nice one by Andreas Hennings, I think! I personally have also question on
deserialization of immutables. Is it going to be possible at all?
Another thing is that PDO will probably not be able to use FETCH_CLASS with
immutables, because of the way it initializes properties.
On Mon, Feb 26, 2018 at
Hi, internals.
As previously said, this week (from *26/02* until *02/03*), I'll open the
RFC `is_countable` for voting.
Here's the link:
https://wiki.php.net/rfc/is-countable#proposed_voting_choices
Thanks for your time,
--
Gabriel Caruso
On Mon, Feb 26, 2018 at 1:05 PM, Nikita Popov wrote:
>
>
> I like the change, but I'm concerned about the technical impact that
> deprecation notice will have. An error handler can convert the notice into
> an exception, which means that zend_hash_next_index_insert is now going
> to be a throwing
Hi!
> It seems that the define is backwards though. ‘#define yyparse zendparse’
> still depends on a zendparse symbol. There is no function definition for
> zendparse. All I can see is yyparse in the generated file. What are your
> thoughts?
Right, yyparse is aliased to zendparse. yyparse is u
