Re: [PHP-DEV] RFC [Discussion]: array_find

[Levi Morrison]

> On 07.04.24 16:35, Larry Garfield wrote:
> > 1. Should this work on arrays or iterables?  This is a long standing 
> > limitation of PHP.  The array operations don't work on iterables, even 
> > though we've had iterables for 20 years.)
>
> In the longer term, it definitely makes sense to create a separate API
> here that can handle not only arrays, but iterables in general. I have
> heard this suggestion in various places (including in the mailing list)
> and had also looked into it in the process of this RFC, but did not
> pursue it further after the initial idea, as it would be important for
> me that such an API is planned accordingly and has an appropriate
> repertoire right from the start (functions such as map, filter, find,
> push, pop, …). In my opinion, a single function would be very out of
> place, especially if this API is then really soon tackled and then
> possibly differs from the implementation of the RFC.

I think it's fine to have an array-specific variant in this case,
because arrays never have duplicate keys. Iterables can, and that may
factor into design. Additionally, arrays are not consumed by iterating
on them, but iterables may, and this could be a gotcha. I think it's
fine to have an array-specific version (simpler, nicer).

Re: [PHP-DEV] RFC [Discussion]: array_find

[Levi Morrison]

On Sun, Apr 7, 2024 at 8:38 AM Larry Garfield  wrote:
>
> On Sun, Apr 7, 2024, at 10:20 AM, Joshua Rüsweg wrote:
> > Hi
> > I have created an RFC to add the function array_find which returns the
> > first element for which a predicate callback returns true. This is a
> > function which I missed often. Furthermore this type of function is
> > implemented with other programming languages like C++, JavaScript and
> > Rust, too.
> > You can find the RFC at:
> > https://wiki.php.net/rfc/array_find
> > Proof of concept implementation is in:
> > https://github.com/joshuaruesweg/php-src/commit/9f3fc252b92f534d498e5f1e6a463e15f45da208
> > I'm looking forward to your feedback.
> > Cheers
> > Joshua Rüsweg
>
> I'm open to this, but two points that I'm sure someone will bring up:
>
> 1. Should this work on arrays or iterables?  This is a long standing 
> limitation of PHP.  The array operations don't work on iterables, even though 
> we've had iterables for 20 years.)
>
> 2. Key handling.  It's good that you have looked into this, because I was 
> going to mention it. :-)  However, I don't think a boolean is the right 
> answer, since the question is binary, not true/false.  (Those are not the 
> same thing.)  I think a small return-mode Enum would make more sense here.

IMO, it's better to separate it into two functions because its type is
stable without control flow. For instance:

// Returns K if $b is true, V otherwise.
function array_find(
array $array,
callable(V, K): bool $callback,
bool $b = false
) -> K|V;

This isn't stable and requires control-flow to understand the type.
These are simpler:

function array_find(
array $array,
callable(V, K): bool $callback
) -> V;

function array_find_key(
array $array,
callable(V, K): bool $callback
) -> K;

Naming bikeshedding aside, it's better to have types that are
inferrable without function-specific knowledge of control flow. It
doesn't matter if it's a bool or an enum, it still has problems.
Better to just separate them to different functions.

Re: External Message: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Robert Landers]

On Wed, Apr 10, 2024 at 10:41 PM Mark Trapp  wrote:
>
> On Wed, Apr 10, 2024 at 9:59 AM Jeffrey Dafoe  wrote:
> >
> > > On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima 
> > >  wrote:
> > > Maybe if such a feedback was given before and it was decided to go for a 
> > > trimmed version of the feature, maybe Ilija/Larry could have had less 
> > > work to implement and test all the variantes they've done. I think if a 
> > > person has such numerous concerns, it should be exposed ASAP even if your 
> > > thoughts are not
> > > totally clear. If you had a chat directly with Ilija/Larry, they would be 
> > > aware of such concerns and would expend efforts to address these concerns.
> >
> > > To an outsider, it looks wild when feedback starts coming in right before 
> > > the vote starts. What's even more startling is that there are people with 
> > > voting rights who have never participated in the discussion at all, yet 
> > > have a right to wordlessly affect the vote's outcome. I sincerely hope 
> > > Ilija and Larry's work don't
> > > go to waste here.
> >
> > I hope that the property hooks feature goes through. I've used it in C# and 
> > it reads nice and saves time.
> >
> > Waiting until the last minute to express a significant design disagreement 
> > is disrespectful of the time the RFC authors have spent working on this 
> > proposal. It's also counterproductive to the PHP project overall.
> >
> > -Jeff
>
> Just a friendly reminder that feedback on why people vote against RFCs
> has been desperately sought after and requested each time a seemingly
> popular RFC is rejected, and the feedback provided by others for this
> RFC was done so in good faith, before voting started, allowing the RFC
> authors to address said feedback should they choose to acknowledge it.
>
> And in general, the wider PHP community does not pay attention to RFCs
> until/unless they come up for a vote.
>
> Admonishing people for providing unexpected or negative feedback will
> have a chilling effect for future RFC attempts, as it's much easier to
> just silently vote no than to be attacked simply for providing a
> dissenting opinion at an inconvenient time.
>
> - Mark

Hey Mark,

I think that is fair, but I'd also point out that RFCs have been
rejected in the past simply because voters felt it was "too last
minute" before a release. I don't think it's fair to decline RFCs for
being too last minute, but when the inverse happens to an RFC: a huge
dissenting opinion at the last second, call foul.

Largely, I agree with you but it's worth pointing out the incongruity here.

Robert Landers
Software Engineer
Utrecht NL

Re: External Message: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Mark Trapp]

On Wed, Apr 10, 2024 at 9:59 AM Jeffrey Dafoe  wrote:
>
> > On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima 
> >  wrote:
> > Maybe if such a feedback was given before and it was decided to go for a 
> > trimmed version of the feature, maybe Ilija/Larry could have had less work 
> > to implement and test all the variantes they've done. I think if a person 
> > has such numerous concerns, it should be exposed ASAP even if your thoughts 
> > are not
> > totally clear. If you had a chat directly with Ilija/Larry, they would be 
> > aware of such concerns and would expend efforts to address these concerns.
>
> > To an outsider, it looks wild when feedback starts coming in right before 
> > the vote starts. What's even more startling is that there are people with 
> > voting rights who have never participated in the discussion at all, yet 
> > have a right to wordlessly affect the vote's outcome. I sincerely hope 
> > Ilija and Larry's work don't
> > go to waste here.
>
> I hope that the property hooks feature goes through. I've used it in C# and 
> it reads nice and saves time.
>
> Waiting until the last minute to express a significant design disagreement is 
> disrespectful of the time the RFC authors have spent working on this 
> proposal. It's also counterproductive to the PHP project overall.
>
> -Jeff

Just a friendly reminder that feedback on why people vote against RFCs
has been desperately sought after and requested each time a seemingly
popular RFC is rejected, and the feedback provided by others for this
RFC was done so in good faith, before voting started, allowing the RFC
authors to address said feedback should they choose to acknowledge it.

And in general, the wider PHP community does not pay attention to RFCs
until/unless they come up for a vote.

Admonishing people for providing unexpected or negative feedback will
have a chilling effect for future RFC attempts, as it's much easier to
just silently vote no than to be attacked simply for providing a
dissenting opinion at an inconvenient time.

- Mark

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Arvids Godjuks]

On Wed, 10 Apr 2024 at 22:31, Tim Düsterhus  wrote:

> Hi
>
> On 4/10/24 10:28, Arvids Godjuks wrote:
> > The amount of complexity in these two hooks is on the level of the whole
> > PHP OOP model with the number of footguns and WTF cases to rival magic
> > quotes, register_globals=on and every other infamous gotcha we had in the
> > engine that got deleted out of existence.
>
> As someone who read the RFC like 20 times while it evolved (and just
> read it once more before submitting this email):
>
> Most of what the RFC spells out explicitly, because that's what RFCs
> need to, is a pretty much natural consequence of how the existing PHP
> features work. You cannot really shorten the RFC without either making
> it underspecified or useless.
>
> Is there some syntax that could technically be omitted? Sure. Would
> doing so meaningfully simplify the RFC? No, because most of the text
> length comes from the interaction of existing syntax and semantics with
> hooks and thus is an inherent property of property hooks (pun not
> intended). It's not the RFCs fault that references exist, or that
> casting an object to an array is legal, or whatever else needs to be
> explicitly spelled out.
>
> I also believe that the chosen syntax fits nicely with the existing
> syntax, borrowing syntax where useful and inventing new syntax where the
> existing syntax does not provide anything.
>
> It's a clear improvement over the status quo of __get() and __set(),
> especially from a third-party tooling perspective. I'm in favor.
>
> Best regards
> Tim Düsterhus
>

Yeah we had a discussion with Larry on SF Slack, he made some things clear
that it's either all or nothing, because once they dove in, it became clear
that there's no way to gradually to introduce it. So, if it passes, the
community is just gonna have to deal with the massive scope of it if they
want the hooks or forget about them.
-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Tim Düsterhus]

Hi

On 4/10/24 10:28, Arvids Godjuks wrote:

The amount of complexity in these two hooks is on the level of the whole
PHP OOP model with the number of footguns and WTF cases to rival magic
quotes, register_globals=on and every other infamous gotcha we had in the
engine that got deleted out of existence.


As someone who read the RFC like 20 times while it evolved (and just 
read it once more before submitting this email):


Most of what the RFC spells out explicitly, because that's what RFCs 
need to, is a pretty much natural consequence of how the existing PHP 
features work. You cannot really shorten the RFC without either making 
it underspecified or useless.


Is there some syntax that could technically be omitted? Sure. Would 
doing so meaningfully simplify the RFC? No, because most of the text 
length comes from the interaction of existing syntax and semantics with 
hooks and thus is an inherent property of property hooks (pun not 
intended). It's not the RFCs fault that references exist, or that 
casting an object to an array is legal, or whatever else needs to be 
explicitly spelled out.


I also believe that the chosen syntax fits nicely with the existing 
syntax, borrowing syntax where useful and inventing new syntax where the 
existing syntax does not provide anything.


It's a clear improvement over the status quo of __get() and __set(), 
especially from a third-party tooling perspective. I'm in favor.


Best regards
Tim Düsterhus

Re: [PHP-DEV] RFC [Discussion]: array_find

[Tim Düsterhus]

Hi

On 4/10/24 00:12, Larry Garfield wrote:

I feel the same. Adding an enum for each binary parameter that is
semantically true and false feels quite unwieldy with how class / enums
/ interfaces are currently organized in the namespace hierarchy.


Point of order: This parameter is *not* semantically true and false.  It is 
semantically either/or, and we kinda twist sideways to make it look like 
true/false if we squint.  That's actually pretty common in the current stdlib, 
though it's not a good approach.  Hence why I asked about an enum.  I wouldn't 
expect it to be single-function, though, but to be applicable for multiple 
functions.  (I did not go looking to see if such functions exist.)


Whoops, I accidentally a word in that paragraph, thank you.

It should have read "each binary parameter that is NOT semantically true 
and false".


Best regards
Tim Düsterhus

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Marco Pivetta]

On Wed, 10 Apr 2024 at 18:52, Erick de Azevedo Lima <
ericklima.c...@gmail.com> wrote:

> > Reminder to not run into a sunk cost fallacy.
>
> My main point was not the cost/work itself, but the fact that big concerns
> should be raised ASAP, and not on the 11th hour, as Robert said.
> Whether we like it or not, the voting right beholders' concerns should be
> taken into account with "special attention", because, well...
> They are the ones that, in the end, decide if your RFC will make it to the
> language or not.
> So having no negative feedback or having it only at the last minute before
> voting is not good at all.
> I think doing this and voting for a "no" for a feature that was so well
> received and discussed extensively by the internalians discourages
> OSS developers from contributing to the language we care so much about.
>

Agreed, but to give you some more context:

 * I know JRF has been holding off feedback about it for a long time,
waiting for the RFC to be more "stable" (i.e. not being a moving flubber)
before posting thoughts
 * I personally usually only get into RFCs very early on (when I have a
clear idea/opinion formed on a topic upfront) or at the end, when the RFC
has gone through the ironing out a lot: the in-between is a brawl for which
24h/day aren't sufficient.

The nature of email threads in a mailing list makes RFCs extremely hard to
approach anything that is "in-flight".

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

RE: External Message: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Jeffrey Dafoe]

> On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima 
>  wrote:
> Maybe if such a feedback was given before and it was decided to go for a 
> trimmed version of the feature, maybe Ilija/Larry could have had less work to 
> implement and test all the variantes they've done. I think if a person has 
> such numerous concerns, it should be exposed ASAP even if your thoughts are 
> not 
> totally clear. If you had a chat directly with Ilija/Larry, they would be 
> aware of such concerns and would expend efforts to address these concerns.

> To an outsider, it looks wild when feedback starts coming in right before the 
> vote starts. What's even more startling is that there are people with voting 
> rights who have never participated in the discussion at all, yet have a right 
> to wordlessly affect the vote's outcome. I sincerely hope Ilija and Larry's 
> work don't 
> go to waste here.

I hope that the property hooks feature goes through. I've used it in C# and it 
reads nice and saves time. 

Waiting until the last minute to express a significant design disagreement is 
disrespectful of the time the RFC authors have spent working on this proposal. 
It's also counterproductive to the PHP project overall. 

-Jeff

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Erick de Azevedo Lima]

> Reminder to not run into a sunk cost fallacy.

My main point was not the cost/work itself, but the fact that big concerns
should be raised ASAP, and not on the 11th hour, as Robert said.
Whether we like it or not, the voting right beholders' concerns should be
taken into account with "special attention", because, well...
They are the ones that, in the end, decide if your RFC will make it to the
language or not.
So having no negative feedback or having it only at the last minute before
voting is not good at all.
I think doing this and voting for a "no" for a feature that was so well
received and discussed extensively by the internalians discourages
OSS developers from contributing to the language we care so much about.

Regards,
Erick

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Saki Takamachi]

Hi Rowan,

> Yes, I agree there's a dilemma there.
> 
> The extra point in favour of TOWARD_ZERO is that it's more efficient, because 
> we don't have to over-calculate and round, just pass scale directly to the 
> implementation. Any other option makes for unnecessary extra calculation in 
> code like this:
> 
> $total = new Number('20');
> $raw_frac = $total / 7;
> $rounded_frac = $raw_frac->round(2, Round::HALF_UP);
> 
> If HALF_UP rounding is the implied default, we have to calculate with scale 
> 11 giving 1.42857142857, round to 1.4285714286, then round again to 1.43.
> 
> If truncation / TOWARD_ZERO is the implied default, we only calculate with 
> scale 10 giving 1.4285714285 and then round once to 1.43.
> 
> (Of course, in this example, the most efficient would be for the user to 
> write $rounded_frac = $total->div(7, 2, Round::HALF_UP) but they might have 
> reasons to keep the division and rounding separate.)

Thanks, when I expand on this issue, I'll also mention the pros and cons of 
both, including the points you mentioned.

Regards,

Saki

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Marco Pivetta]

On Wed, 10 Apr 2024 at 16:56, Alex Wells  wrote:

> On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima <
> ericklima.c...@gmail.com> wrote:
>
>> Maybe if such a feedback was given before and it was decided to go for a
>> trimmed version of the feature, maybe Ilija/Larry could have had less work
>> to implement and test all the variantes they've done. I think if a person
>> has such numerous concerns, it should be exposed ASAP even if your thoughts
>> are not totally clear. If you had a chat directly with Ilija/Larry, they
>> would be aware of such concerns and would expend efforts to address these
>> concerns.
>>
>
> To an outsider, it looks wild when feedback starts coming in right before
> the vote starts. What's even more startling is that there are people with
> voting rights who have never participated in the discussion at all, yet
> have a right to wordlessly affect the vote's outcome. I sincerely hope
> Ilija and Larry's work don't go to waste here.
>

Reminder to not run into a sunk cost fallacy.
I totally understand the sentiment around the work done, but the outcome is
something very impactful.
Work may or may not be wasted, but that's the nature of RFCs.


The current RFC makes a lot of people uneasy, and JRF's comment resonates
strongly with my opinion.
To me, further overloading the arrow (`->`) operator with this much added
context is a mistake, regardless of how much detail was added in handling
all the weird edge cases of the language: in fact, going as far as
exploring by-ref semantics (instead of just saying "no" to them) is also a
big problem.

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Saki Takamachi]

Hi,

> To an outsider, it looks wild when feedback starts coming in right before the 
> vote starts. What's even more startling is that there are people with voting 
> rights who have never participated in the discussion at all, yet have a right 
> to wordlessly affect the vote's outcome. I sincerely hope Ilija and Larry's 
> work don't go to waste here.


I was also one of those who did not speak out because I was in favor of this 
RFC.

The syntax is new and may look unfamiliar, but people should soon get used to 
it. Also, I personally don't think the functionality of property hooks is 
complicated. Since this is a new feature, the amount of information may be a 
little large during initial learning, but the feature itself is not that 
complicated.

Regards,

Saki

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[ericmann]

On 4/10/24 07:56, Alex Wells wrote:
To an outsider, it looks wild when feedback starts coming in right 
before the vote starts. What's even more startling is that there are 
people with voting rights who have never participated in the 
discussion at all, yet have a right to wordlessly affect the vote's 
outcome. I sincerely hope Ilija and Larry's work don't go to waste here.

--
Clearly those of us who agreed with the approach and wanted the RFC and 
planned to vote to approve things should've been more vocal about that. 
Don't take silence to be apathy - email is often the worst medium for a 
deep discussion and "ditto" doesn't add to the discourse.


I for one will try to be more vocal since apparently what I thought was 
noise is apparently necessary signal here.


Is the feature complex? Yes. Is it overly complex? No. As a developer 
who has hand-rolled custom getter/setter behavior for years this will 
save a mountain of time (and would've removed nearly half of the code I 
once had to write for a very complicated WordPress feature). I love the 
approach and wholeheartedly support the direction here. The similarity 
to C# and Kotlin structures should lower the cognitive burden here as well.

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Bilge]

On 10/04/2024 15:56, Alex Wells wrote:
To an outsider, it looks wild when feedback starts coming in right 
before the vote starts. What's even more startling is that there are 
people with voting rights who have never participated in the 
discussion at all, yet have a right to wordlessly affect the vote's 
outcome. I sincerely hope Ilija and Larry's work don't go to waste here.


There are always people afraid of change. I just hope they don't stand 
in the way of progress.

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Nicolas Grekas]

Hi Ilija, Larry,

Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:
> https://wiki.php.net/rfc/property-hooks
>

I would make 3 changes to the RFC if I were in charge :

   - I'd make $this->propName inside a hook access the parent property via
   its hooks if any. I'd do this because that'd provide
   encapsulation-by-default for inheritance. Aka a parent class could
   reasonably expect its child classes to get through its hooks. (I'd be fine
   with only allowing the "=" operator on this.)
   - I'd keep the special $field value to access the backing value. It's a
   clear way to signify that accessing the raw value is possible only in
   hooks, never in other methods.
   - And I'd consider forbidding any method calls in hooks except static
   methods. This would allow factorising functional logic without opening for
   side-effects on the object outside of hooks themselves.

I'm sharing this in case it rings a bell somewhere, but I can work with the
peculiarities of the current RFC and I must admit I didn't spend as much
time as you on the topic so my proposals might fall short, while yours to
actually work. Thanks for that :)

I'm in favor of the RFC.

Cheers,
Nicolas

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Alex Wells]

On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima <
ericklima.c...@gmail.com> wrote:

> Maybe if such a feedback was given before and it was decided to go for a
> trimmed version of the feature, maybe Ilija/Larry could have had less work
> to implement and test all the variantes they've done. I think if a person
> has such numerous concerns, it should be exposed ASAP even if your thoughts
> are not totally clear. If you had a chat directly with Ilija/Larry, they
> would be aware of such concerns and would expend efforts to address these
> concerns.
>

To an outsider, it looks wild when feedback starts coming in right before
the vote starts. What's even more startling is that there are people with
voting rights who have never participated in the discussion at all, yet
have a right to wordlessly affect the vote's outcome. I sincerely hope
Ilija and Larry's work don't go to waste here.

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Rowan Tommins [IMSoP]]

On 10 April 2024 10:38:44 BST, Saki Takamachi  wrote:

>I was thinking about this today, and I think both are correct opinions on 
>whether to set the initial value to HALF_UP or TOWARD_ZERO. It's just a matter 
>of prioritizing whether consistency with existing behavior or consistency 
>within a class, and they can never be met simultaneously.

Yes, I agree there's a dilemma there.

The extra point in favour of TOWARD_ZERO is that it's more efficient, because 
we don't have to over-calculate and round, just pass scale directly to the 
implementation. Any other option makes for unnecessary extra calculation in 
code like this:

$total = new Number('20');
$raw_frac = $total / 7;
$rounded_frac = $raw_frac->round(2, Round::HALF_UP);

If HALF_UP rounding is the implied default, we have to calculate with scale 11 
giving 1.42857142857, round to 1.4285714286, then round again to 1.43.

If truncation / TOWARD_ZERO is the implied default, we only calculate with 
scale 10 giving 1.4285714285 and then round once to 1.43.

(Of course, in this example, the most efficient would be for the user to write 
$rounded_frac = $total->div(7, 2, Round::HALF_UP) but they might have reasons 
to keep the division and rounding separate.)

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Erick de Azevedo Lima]

> As someone who has spent a number of years writing C#, the RFC look>
quite sane.
Same here.

> Removing it because "it complicates things" isn't really a good reason,
IMHO.
I think the same. FFI, for instance, is powerful but one can make a mess
with it.

> Then watching the feedback here, at the 11th hour, is super saddening.
Again, same here . If this feedback was given during the "heat of the
discussion", maybe it could lead the discussion to a place where less
variants would
be introduced on this first implementation and a shorter syntax could be
introduced later on, like the arrow functions were introduced after
anonymous functions.

Maybe if such a feedback was given before and it was decided to go for a
trimmed version of the feature, maybe Ilija/Larry could have had less work
to implement and test all the variantes they've done. I think if a person
has such numerous concerns, it should be exposed ASAP even if your thoughts
are not totally clear. If you had a chat directly with Ilija/Larry, they
would be aware of such concerns and would expend efforts to address these
concerns.

Regards,
Erick

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Matteo Beccati]

Hi,

Il 10/04/2024 05:40, Juliette Reinders Folmer ha scritto:

---
TL;DR: this RFC tries to do too much in one go and introduces a huge 
amount of cognitive complexity with all the exceptions and the 
differences in behaviour between virtual and backed properties. This 
cognitive complexity is so high that I expect that the feature will 
catch most developers out a lot of the time.

---


Thanks Juliette for the excellent write-up (I quoted the TL;DR just for 
brevity).


At first what the RFC promises looks incredibly shiny and got me very 
excited. The work done by Larry and Ilija is certainly brilliant, but 
the complexity is so big that I feel we should aim for a trimmed down 
version to make it easier to grasp and to work with, e.g. less syntax 
variants (no short or constructor promotion), and perhaps no virtual 
properties.



Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Robert Landers]

On Wed, Apr 10, 2024 at 5:49 AM Juliette Reinders Folmer
 wrote:
>
> On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
>
> On 8-4-2024 23:39, Ilija Tovilo wrote:
>
> Hi everyone
>
> Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:
> https://wiki.php.net/rfc/property-hooks
>
> We have worked long and hard on this RFC, and hope that we have found
> some middle-ground that works for the majority. One last concern we
> have not officially clarified on the list:
>
> https://externals.io/message/122445#122667
>
> I personally do not feel strongly about whether asymmetric types make it into 
> the initial implementation. Larry does, however, and I think it is not fair 
> to exclude them without providing any concrete reasons not to. [snip]
>
> My concern is more about the external impact of what is effectively a change 
> to the type system of the language: [snip] will tools like PhpStan and Psalm 
> require complex changes to analyse code using such properties?
>
> In particular, this paragraph is referencing the ability to widen the
> accepted $value parameter type of the set hook, described at the
> bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
> to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
> this should not be complex to implement in PHPStan. In fact, PHPStan
> already offers the @property-read and @property-write class
> annotations, which can be used to describe "virtual" properties
> handled within __get/__set, already providing asymmetric types of
> sorts. Hence, this concern should be a non-issue.
>
> Thank you to everybody who has contributed to the discussion!
>
> Ilija
>
>
> Ilija,
>
> Heads-up: I'm still writing up an opinion and intend to send it to the list 
> before end of day (CET). I know I'm late to the party, but I've been having 
> trouble finding the words to express myself properly regarding this RFC (and 
> have been struggling to find the right words for months).
>
> Smile,
> Juliette
>
>
> Later than intended, but here goes
>
> If there is one RFC which has been giving me nightmares since I first heard 
> of it, it's this one.
>
> I realize it is late in the discussion period to speak up, but for months 
> I've been trying to find the words to express my concerns in a polite and 
> constructive way and have failed.
>
> I am going to try now anyway (before it is too late), so please bear with me. 
> Also, as I'm not a C-developer, please forgive me if I get the internals 
> wrong. I'm writing this from a PHP-dev/user perspective, with my perspective 
> being heavily influenced by my role as maintainer of PHP_CodeSniffer.
>
> ---
> TL;DR: this RFC tries to do too much in one go and introduces a huge amount 
> of cognitive complexity with all the exceptions and the differences in 
> behaviour between virtual and backed properties. This cognitive complexity is 
> so high that I expect that the feature will catch most developers out a lot 
> of the time.
> ---
>
> I can definitely see the use case and desirability of the property hooks 
> functionality proposed in the RFC and compared to the initial RFC I read last 
> year, the current RFC is, IMO, much improved.
> Huge kudos to Ilija and Larry for all the work they have put in to this!
>
> I applaud the intention of this RFC to make it easier to avoid the magic 
> __get()/__set() et al methods. What I have a problem with is the 
> implementation details.
>
> Over the last few years, we've seen a movement to get rid of more and more of 
> the _surprising_ behaviour of PHP, with subtle exceptions being deprecated 
> and slated for removal and (most) new syntaxes trying to use the principle of 
> least surprise by design.
>
> This RFC, in my view, is in stark contrast to this as it introduces a 
> plethora of exceptions and subtle different behaviour in a way that will 
> catch developers out for years to come.
>
> At this moment (excluding property hooks), from a user perspective, there are 
> three different function syntaxes in PHP: named functions (and methods), 
> anonymous functions and arrow functions.
>
> The semantics of these are very similar with subtle differences:
> * Can be static or non-static.
> * Take parameters, which can be typed, references, variadic, optional etc.
> * Can have a return type.
> * Can return by reference.
> * Have a function "body".
>
> The differences between the current syntaxes - from a user perspective - are 
> as follows:
> = Named functions:
> * When declared in a class, can have visibility attached, can be abstract, 
> can be final.
> * When declared in an interface or declared as abstract, will not have a 
> function "body".
>
> = Anonymous functions:
> * Can import plain variables from outside its scope with a `use()` clause.
> * Are declared as an expression (can be assigned to a variable etc).
>
> = Arrow functions:
> * Have access to variables in the same scope.
> * Are declared as an expression.
> * Body of 

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Saki Takamachi]

Hi Rowan,

> That's why I mentioned the two different groups of users. The scale and 
> rounding mode aren't there for group (a), who just want the scale to be 
> managed automatically; they are there for group (b), who want to guarantee a 
> particular result has a particular scale. The result of $a->add($b, 2, 
> Round::HALF_UP) will always be the same as $a->add($b)->round(Round::HALF_UP) 
>  but is more convenient, and in some cases more efficient, since it doesn't 
> calculate unnecessary digits.
> 
> Remember also the title and original aim of the RFC: add object support to 
> BCMath. The scale parameter is already there on the existing functions 
> (bcadd, bcmul, etc), so removing it on the object version would be 
> surprising. The rounding mode is a new feature, but there doesn't seem a good 
> reason not to include it everywhere as well.

Ah, I understand. There may certainly be use cases where demand specifies a 
scale smaller than the maximum scale in order to save computational costs. That 
makes sense to me.

Also, considering the two groups you presented, the group that wants to control 
the scale is probably not going to use operator calculations, even though they 
could provide various options in the constructor. Unless look at the contents 
of objects in the calculation process using var_dump or something, can't 
understand the state just by looking at the code, which can lead to bugs. They 
probably don't like that kind of code.


> Again, the aim was to match the functionality of the existing functions. It's 
> likely that users will migrate code written using bcdiv() to use 
> BCMath\Number->div() and expect it to work the same, at least when specifying 
> a scale. Having it behave differently by rounding up the last digit by 
> default seems like a bad idea.
> 
> Thinking about the implementation, the truncation behaviour also makes sense: 
> the library isn't actually rounding anything, it's calculating digit by 
> digit, and stopping when it reaches the requested scale.
> 
> The whole concept of rounding is something that we are adding, presumably by 
> passing $scale+1 to the underlying library functions. It's a nice feature to 
> add, but not one that should be on by default, given we're not writing the 
> extension from scratch.

I was thinking about this today, and I think both are correct opinions on 
whether to set the initial value to HALF_UP or TOWARD_ZERO. It's just a matter 
of prioritizing whether consistency with existing behavior or consistency 
within a class, and they can never be met simultaneously.

Therefore, I am considering adding a more detailed explanation to the RFC on 
this issue and taking a second vote to decide.

Regards.

Saki

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Arvids Godjuks]

On Wed, 10 Apr 2024 at 06:43, Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:

> On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
>
> On 8-4-2024 23:39, Ilija Tovilo wrote:
>
> Hi everyone
>
> Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:https://wiki.php.net/rfc/property-hooks
>
> We have worked long and hard on this RFC, and hope that we have found
> some middle-ground that works for the majority. One last concern we
> have not officially clarified on the list:
> https://externals.io/message/122445#122667
>
> I personally do not feel strongly about whether asymmetric types make it into 
> the initial implementation. Larry does, however, and I think it is not fair 
> to exclude them without providing any concrete reasons not to. [snip]
>
> My concern is more about the external impact of what is effectively a change 
> to the type system of the language: [snip] will tools like PhpStan and Psalm 
> require complex changes to analyse code using such properties?
>
> In particular, this paragraph is referencing the ability to widen the
> accepted $value parameter type of the set hook, described at the
> bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
> to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
> this should not be complex to implement in PHPStan. In fact, PHPStan
> already offers the @property-read and @property-write class
> annotations, which can be used to describe "virtual" properties
> handled within __get/__set, already providing asymmetric types of
> sorts. Hence, this concern should be a non-issue.
>
> Thank you to everybody who has contributed to the discussion!
>
> Ilija
>
>
>
> Ilija,
>
> Heads-up: I'm still writing up an opinion and intend to send it to the
> list before end of day (CET). I know I'm late to the party, but I've been
> having trouble finding the words to express myself properly regarding this
> RFC (and have been struggling to find the right words for months).
>
> Smile,
> Juliette
>
>
> Later than intended, but here goes
>
> If there is one RFC which has been giving me nightmares since I first
> heard of it, it's this one.
>
> I realize it is late in the discussion period to speak up, but for months
> I've been trying to find the words to express my concerns in a polite and
> constructive way and have failed.
>
> I am going to try now anyway (before it is too late), so please bear with
> me. Also, as I'm not a C-developer, please forgive me if I get the
> internals wrong. I'm writing this from a PHP-dev/user perspective, with my
> perspective being heavily influenced by my role as maintainer of
> PHP_CodeSniffer.
>
> ---
> TL;DR: this RFC tries to do too much in one go and introduces a huge
> amount of cognitive complexity with all the exceptions and the differences
> in behaviour between virtual and backed properties. This cognitive
> complexity is so high that I expect that the feature will catch most
> developers out a lot of the time.
> ---
>
> I can definitely see the use case and desirability of the property hooks
> functionality proposed in the RFC and compared to the initial RFC I read
> last year, the current RFC is, IMO, much improved.
> Huge kudos to Ilija and Larry for all the work they have put in to this!
>
> I applaud the intention of this RFC to make it easier to avoid the magic
> __get()/__set() et al methods. What I have a problem with is the
> implementation details.
>
> Over the last few years, we've seen a movement to get rid of more and more
> of the _surprising_ behaviour of PHP, with subtle exceptions being
> deprecated and slated for removal and (most) new syntaxes trying to use the
> principle of least surprise by design.
>
> This RFC, in my view, is in stark contrast to this as it introduces a
> plethora of exceptions and subtle different behaviour in a way that will
> catch developers out for years to come.
>
> At this moment (excluding property hooks), from a user perspective, there
> are three different function syntaxes in PHP: named functions (and
> methods), anonymous functions and arrow functions.
>
> The semantics of these are very similar with subtle differences:
> * Can be static or non-static.
> * Take parameters, which can be typed, references, variadic, optional etc.
> * Can have a return type.
> * Can return by reference.
> * Have a function "body".
>
> The differences between the current syntaxes - from a user perspective -
> are as follows:
> = Named functions:
> * When declared in a class, can have visibility attached, can be abstract,
> can be final.
> * When declared in an interface or declared as abstract, will not have a
> function "body".
>
> = Anonymous functions:
> * Can import plain variables from outside its scope with a `use()` clause.
> * Are declared as an expression (can be assigned to a variable etc).
>
> = Arrow functions:
> * Have access to variables in the same scope.
> * Are declared as an expression.
> * 

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Lynn]

On Wed, Apr 10, 2024 at 5:47 AM Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:

> On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
>
> On 8-4-2024 23:39, Ilija Tovilo wrote:
>
> Hi everyone
>
> Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:https://wiki.php.net/rfc/property-hooks
>
> We have worked long and hard on this RFC, and hope that we have found
> some middle-ground that works for the majority. One last concern we
> have not officially clarified on the list:
> https://externals.io/message/122445#122667
>
> I personally do not feel strongly about whether asymmetric types make it into 
> the initial implementation. Larry does, however, and I think it is not fair 
> to exclude them without providing any concrete reasons not to. [snip]
>
> My concern is more about the external impact of what is effectively a change 
> to the type system of the language: [snip] will tools like PhpStan and Psalm 
> require complex changes to analyse code using such properties?
>
> In particular, this paragraph is referencing the ability to widen the
> accepted $value parameter type of the set hook, described at the
> bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
> to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
> this should not be complex to implement in PHPStan. In fact, PHPStan
> already offers the @property-read and @property-write class
> annotations, which can be used to describe "virtual" properties
> handled within __get/__set, already providing asymmetric types of
> sorts. Hence, this concern should be a non-issue.
>
> Thank you to everybody who has contributed to the discussion!
>
> Ilija
>
>
>
> Ilija,
>
> Heads-up: I'm still writing up an opinion and intend to send it to the
> list before end of day (CET). I know I'm late to the party, but I've been
> having trouble finding the words to express myself properly regarding this
> RFC (and have been struggling to find the right words for months).
>
> Smile,
> Juliette
>
>
> Later than intended, but here goes
>
> If there is one RFC which has been giving me nightmares since I first
> heard of it, it's this one.
>
> I realize it is late in the discussion period to speak up, but for months
> I've been trying to find the words to express my concerns in a polite and
> constructive way and have failed.
>
> I am going to try now anyway (before it is too late), so please bear with
> me. Also, as I'm not a C-developer, please forgive me if I get the
> internals wrong. I'm writing this from a PHP-dev/user perspective, with my
> perspective being heavily influenced by my role as maintainer of
> PHP_CodeSniffer.
>
> ---
> TL;DR: this RFC tries to do too much in one go and introduces a huge
> amount of cognitive complexity with all the exceptions and the differences
> in behaviour between virtual and backed properties. This cognitive
> complexity is so high that I expect that the feature will catch most
> developers out a lot of the time.
> ---
>
> I can definitely see the use case and desirability of the property hooks
> functionality proposed in the RFC and compared to the initial RFC I read
> last year, the current RFC is, IMO, much improved.
> Huge kudos to Ilija and Larry for all the work they have put in to this!
>
> I applaud the intention of this RFC to make it easier to avoid the magic
> __get()/__set() et al methods. What I have a problem with is the
> implementation details.
>
> Over the last few years, we've seen a movement to get rid of more and more
> of the _surprising_ behaviour of PHP, with subtle exceptions being
> deprecated and slated for removal and (most) new syntaxes trying to use the
> principle of least surprise by design.
>
> This RFC, in my view, is in stark contrast to this as it introduces a
> plethora of exceptions and subtle different behaviour in a way that will
> catch developers out for years to come.
>
> At this moment (excluding property hooks), from a user perspective, there
> are three different function syntaxes in PHP: named functions (and
> methods), anonymous functions and arrow functions.
>
> The semantics of these are very similar with subtle differences:
> * Can be static or non-static.
> * Take parameters, which can be typed, references, variadic, optional etc.
> * Can have a return type.
> * Can return by reference.
> * Have a function "body".
>
> The differences between the current syntaxes - from a user perspective -
> are as follows:
> = Named functions:
> * When declared in a class, can have visibility attached, can be abstract,
> can be final.
> * When declared in an interface or declared as abstract, will not have a
> function "body".
>
> = Anonymous functions:
> * Can import plain variables from outside its scope with a `use()` clause.
> * Are declared as an expression (can be assigned to a variable etc).
>
> = Arrow functions:
> * Have access to variables in the same scope.
> * Are declared as an expression.
> * 

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

[Rowan Tommins [IMSoP]]

On 10 April 2024 00:36:21 BST, Saki Takamachi  wrote:
>- The scale and rounding mode are not required for example in add, since the 
>scale of the result will never be infinite and we can automatically calculate 
>the scale needed to fit the result. Does adding those two options to all 
>calculations mean adding them to calculations like add as well?

That's why I mentioned the two different groups of users. The scale and 
rounding mode aren't there for group (a), who just want the scale to be managed 
automatically; they are there for group (b), who want to guarantee a particular 
result has a particular scale. The result of $a->add($b, 2, Round::HALF_UP) 
will always be the same as $a->add($b)->round(Round::HALF_UP)  but is more 
convenient, and in some cases more efficient, since it doesn't calculate 
unnecessary digits. 

Remember also the title and original aim of the RFC: add object support to 
BCMath. The scale parameter is already there on the existing functions (bcadd, 
bcmul, etc), so removing it on the object version would be surprising. The 
rounding mode is a new feature, but there doesn't seem a good reason not to 
include it everywhere as well.



>- As Tim mentioned, it may be confusing to have an initial value separate from 
>the mode of the `round()` method. Would it make sense to have an initial value 
>of HALF_UP?

Again, the aim was to match the functionality of the existing functions. It's 
likely that users will migrate code written using bcdiv() to use 
BCMath\Number->div() and expect it to work the same, at least when specifying a 
scale. Having it behave differently by rounding up the last digit by default 
seems like a bad idea. 

Thinking about the implementation, the truncation behaviour also makes sense: 
the library isn't actually rounding anything, it's calculating digit by digit, 
and stopping when it reaches the requested scale.

The whole concept of rounding is something that we are adding, presumably by 
passing $scale+1 to the underlying library functions. It's a nice feature to 
add, but not one that should be on by default, given we're not writing the 
extension from scratch.


Regards,
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?

[Arvids Godjuks]

On Tue, 9 Apr 2024 at 09:57, Rowan Tommins [IMSoP] 
wrote:

>
>
> On 8 April 2024 21:51:46 BST, Jordan LeDoux 
> wrote:
> >I have mentioned before that my understanding of the deeper aspects of how
> >zvals work is very lacking compared to some others, so this is very
> >helpful.
>
> My own knowledge definitely has gaps and errors, and comes mostly from
> introductions like https://www.phpinternalsbook.com/ and in this case
> Nikita's blog articles about the changes in 7.0:
> https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html
>
>
> > I confess that I do not
> >understand the technical intricacies of the interned strings and packed
> >arrays, I just understand that the zval structure for these arbitrary
> >precision values would probably be non-trivial, and from what I was able
> to
> >research and determine that was in part related to the 64bit zval limit.
>
> From previous discussions, I gather that the hardest part of implementing
> a new zval type is probably not the memory structure itself - that will
> mostly be handled in a few key functions and macros - but the sheer number
> of places that do something different with each zval type and will need
> updating. Searching for Z_TYPE_P, which is just one of the macros used for
> that purpose, shows over 200 lines to check:
> https://heap.space/search?project=php-src=Z_TYPE_P=c
>
> That's why it's so much easier to wrap a new type in an object, because
> then all of those code paths are considered for you, you just have a fixed
> set of handlers to implement. If Ilija's "data classes" proposal
> progresses, you'll be able to have copy-on-write for free as well.
>
> Regards,
> Rowan Tommins
> [IMSoP]
>

So I'd like to conclude this thread since we have dedicated threads for
each of the topics here.

In my opinion, we should go with both. Both topics cover quite different
things. Personally, I'm not really interested in BCMath part as much
because I do not see me needing it (never did before, don't force me
getting into an industry where it would be required to have numbers that
large). But I am interested in a native decimal that would cover the vast
majority of the uses and be on part with integer and float number types.
If my stance makes sense, I then shall join the native decimal thread and
continue there.

-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius