Re: [PHP-DEV] definition of zendparse

[Thomas Punt]

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 used for the symbol 
definition name (instead of zendparse) in the generated parser[1], where it 
will be replaced with zendparse by the preprocessor.

Thanks,
Tom

[1]: 
https://gist.github.com/tpunt/c22aea1602594d6cfcc94f801d580241#file-zend_language_parser-c-L4489

Re: [PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

[Pedro Magalhães]

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 operation. Apart from the fact that the currently linked
> implementation is not exception-safe (if the deprecation notice throws, the
> element is still inserted), it's quite likely that at least some of the
> >250 uses of zend_hash_next_index_insert will not deal with exceptions
> correctly.
>
> Nikita
>

Hi Nikita, thanks for the feedback.

About the implementation of the deprecation notice, I agree that it should
be updated to be exception-safe.

About the issue if it being dealt with correctly everywhere, I'm honestly
more inclined towards dealing with it when/if it becomes a problem. I think
the number of users that 1) Start an array with a negative number, 2) Use
implicit keys afterwards and 3) Promote Notices to Exceptions must be a
very very small subset. Would you consider this an acceptable approach for
this specific case?

Thanks,
Pedro

[PHP-DEV] [VOTE] is_countable

[Gabriel Caruso]

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

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Crocodile]

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 4:13 PM Andreas Hennings 
wrote:

> 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, then return the clone.
> This would already not work if the property is marked as immutable
> with the proposed feature.
>
> Also static method constructors that write directly on the object
> would not work, because technically they are not part of the
> constructor.
>
> For private properties the proposed feature would add little benefit.
> Any private property can be made practically immutable by writing the
> class accordingly: Not having setters, etc.
>
> Where this feature would become useful is if someone prefers public
> properties over getter methods.
> But again, this would prevent any unconventional constructor, like
> withers or static factories.
>
> I think a better and more useful feature would be read-public,
> write-private.
> Maybe like this? https://wiki.php.net/rfc/readonly_properties
> (For some reason I cannot open the RFC wiki pages. Maybe they are down?)
>
> This would achieve the same goal: Making a property practically immutable.
> But it would still allow unconventional constructors.
> It would be the implementor's job to decide which method should be
> allowed to modify a property, and which shouldn't.
>
>
>
> On 26 February 2018 at 13:52, Silvio Marijić 
> wrote:
> > 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 with upstream
> > master couple days ago, might be a reason.
> >
> > I would appreciate if anyone could give me hand on this ?
> >
> > On Feb 26, 2018 1:48 PM, "Silvio Marijić" 
> wrote:
> >
> >> 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 with upstream
> >> master couple days ago, might be a reason.
> >>
> >> I would appreciate if anyone could give me hand on this ?
> >>
> >> On Feb 26, 2018 1:44 PM, marijic.sil...@gmail.com wrote:
> >>
> >> 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 "immutable".
> >>
> >> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones  wrote:
> >>
> >>>
> >>>
> >>> > On Feb 25, 2018, at 12:59, Silvio Marijić 
> >>> wrote:
> >>> >
> >>> > Here is link to tweet https://twitter.com/SilvioMari
> >>> jic/status/965564630071300096
> >>>
> >>> After having read that, I think "immutable" is still perfectly
> reasonable.
> >>>
> >>>
> >>> --
> >>> Paul M. Jones
> >>> pmjo...@pmjones.io
> >>> http://paul-m-jones.com
> >>>
> >>> Modernizing Legacy Applications in PHP
> >>> https://leanpub.com/mlaphp
> >>>
> >>> Solving the N+1 Problem in PHP
> >>> https://leanpub.com/sn1php
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>> --
> >> Best regards,
> >> Victor Bolshov
> >>
> >>
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Andreas Hennings]

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, then return the clone.
This would already not work if the property is marked as immutable
with the proposed feature.

Also static method constructors that write directly on the object
would not work, because technically they are not part of the
constructor.

For private properties the proposed feature would add little benefit.
Any private property can be made practically immutable by writing the
class accordingly: Not having setters, etc.

Where this feature would become useful is if someone prefers public
properties over getter methods.
But again, this would prevent any unconventional constructor, like
withers or static factories.

I think a better and more useful feature would be read-public, write-private.
Maybe like this? https://wiki.php.net/rfc/readonly_properties
(For some reason I cannot open the RFC wiki pages. Maybe they are down?)

This would achieve the same goal: Making a property practically immutable.
But it would still allow unconventional constructors.
It would be the implementor's job to decide which method should be
allowed to modify a property, and which shouldn't.



On 26 February 2018 at 13:52, Silvio Marijić  wrote:
> 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 with upstream
> master couple days ago, might be a reason.
>
> I would appreciate if anyone could give me hand on this ?
>
> On Feb 26, 2018 1:48 PM, "Silvio Marijić"  wrote:
>
>> 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 with upstream
>> master couple days ago, might be a reason.
>>
>> I would appreciate if anyone could give me hand on this ?
>>
>> On Feb 26, 2018 1:44 PM, marijic.sil...@gmail.com wrote:
>>
>> 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 "immutable".
>>
>> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones  wrote:
>>
>>>
>>>
>>> > On Feb 25, 2018, at 12:59, Silvio Marijić 
>>> wrote:
>>> >
>>> > Here is link to tweet https://twitter.com/SilvioMari
>>> jic/status/965564630071300096
>>>
>>> After having read that, I think "immutable" is still perfectly reasonable.
>>>
>>>
>>> --
>>> Paul M. Jones
>>> pmjo...@pmjones.io
>>> http://paul-m-jones.com
>>>
>>> Modernizing Legacy Applications in PHP
>>> https://leanpub.com/mlaphp
>>>
>>> Solving the N+1 Problem in PHP
>>> https://leanpub.com/sn1php
>>>
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>> --
>> Best regards,
>> Victor Bolshov
>>
>>
>>
>>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Arrays starting with a negative index

[Nikita Popov]

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 minor
> version. On a second attempt targeting 8.0 I have also canceled the vote as
> the inclusion of a deprecation notice in cases where the behavior will
> change warranted further discussion.
>
> To address these issues, the current version of the RFC will have 2
> separate votes:
> - Introduce the new behavior on 8.0
> - Introduce a deprecation notice on 7.3
>
> For those not familiar with the RFC, the general idea is that currently,
> any array that has a number n as it's first numeric key will have for it's
> next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
> make this consistent by always using n+1 regardless of the sign of n.
> In code:
> $a[-2] = true; // Current: Key is -2, RFC: Key is -2
> $a[] = true; // Current: Key is 0, RFC: Key is -1
> $a[] = true; // Current: Key is 1, RFC: Key is 0
>
> I invite you to read the full RFC:
> https://wiki.php.net/rfc/negative_array_index and bring up any issues you
> see with the current version before the voting period starts.
>
> Looking forward for any feedback.
>
> Regards,
> Pedro Magalhães
>

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 operation. Apart from the fact that the currently linked
implementation is not exception-safe (if the deprecation notice throws, the
element is still inserted), it's quite likely that at least some of the
>250 uses of zend_hash_next_index_insert will not deal with exceptions
correctly.

Nikita

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Silvio Marijić]

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 with upstream
master couple days ago, might be a reason.

I would appreciate if anyone could give me hand on this ?

On Feb 26, 2018 1:48 PM, "Silvio Marijić"  wrote:

> 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 with upstream
> master couple days ago, might be a reason.
>
> I would appreciate if anyone could give me hand on this ?
>
> On Feb 26, 2018 1:44 PM, marijic.sil...@gmail.com wrote:
>
> 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 "immutable".
>
> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones  wrote:
>
>>
>>
>> > On Feb 25, 2018, at 12:59, Silvio Marijić 
>> wrote:
>> >
>> > Here is link to tweet https://twitter.com/SilvioMari
>> jic/status/965564630071300096
>>
>> After having read that, I think "immutable" is still perfectly reasonable.
>>
>>
>> --
>> Paul M. Jones
>> pmjo...@pmjones.io
>> http://paul-m-jones.com
>>
>> Modernizing Legacy Applications in PHP
>> https://leanpub.com/mlaphp
>>
>> Solving the N+1 Problem in PHP
>> https://leanpub.com/sn1php
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> --
> Best regards,
> Victor Bolshov
>
>
>
>

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Silvio Marijić]

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 "immutable".
>
> On Sun, Feb 25, 2018 at 8:02 PM Paul Jones  wrote:
>
>>
>>
>> > On Feb 25, 2018, at 12:59, Silvio Marijić 
>> wrote:
>> >
>> > Here is link to tweet https://twitter.com/SilvioMarijic/status/
>> 965564630071300096
>>
>> After having read that, I think "immutable" is still perfectly reasonable.
>>
>>
>> --
>> Paul M. Jones
>> pmjo...@pmjones.io
>> http://paul-m-jones.com
>>
>> Modernizing Legacy Applications in PHP
>> https://leanpub.com/mlaphp
>>
>> Solving the N+1 Problem in PHP
>> https://leanpub.com/sn1php
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> --
> Best regards,
> Victor Bolshov
>

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Crocodile]

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ć 
> wrote:
> >
> > Here is link to tweet
> https://twitter.com/SilvioMarijic/status/965564630071300096
>
> After having read that, I think "immutable" is still perfectly reasonable.
>
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov