Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
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 ofhttps://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 the function starts with a => instead of being enclosed in curlies and can end on a range of characters. * Can only take one statement in the body. * Automagically returns. The property hooks RFC introduces a fourth flavour of function syntax. And not
Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
2024年3月26日(火) 23:49 youkidearitai : > > 2024年3月26日(火) 21:58 Peter Kokot : > > > > On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote: > > > > > > Hi, Internals > > > > > > Sorry I mistake. > > > Send again. > > > > > > grapheme_str_split going to "Voting" phase. > > > Vote end is 10th April 00:00 GMT > > > > > > Regards > > > Yuya > > > > > > -- > > > --- > > > Yuya Hamada (tekimen) > > > - https://tekitoh-memdhoi.info > > > - https://github.com/youkidearitai > > > - > > > > And a link is this one for those wondering where to click: > > https://wiki.php.net/rfc/grapheme_str_split > > Thank you very much, Peter. > I forgot link. Thanks again. > > Regards > Yuya > > -- > --- > Yuya Hamada (tekimen) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - Hi, Internals grapheme_str_split is voting end, result is Yes: 19 No: 0 that is accepted. Thank you for voting and for your discussion and interest in Unicode. I'm going to implements. Cheers Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
postscript: The `precision` of `round()` can be negative. I'm not sure if this should be called `scale`. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Hi Rowan,
a).
> I propose:
>
> - The constructor accepts string|int $num only.
>
> - All operations accept an optional scale and rounding mode.
>
> - If no rounding mode is provided, the default behaviour is to truncate. This
> means that (new BCMath\Number('20'))->div(3, 5) has the same result as
> bcdiv('20', '3', 5) which is 6.6
>
> - If a rounding mode is provided, the object transparently calculates one
> extra digit of scale, then rounds according to the specified mode.
>
> - If no scale is provided, most operations will automatically calculate the
> required scale, e.g. add will use the larger of the two scales. This is the
> same as the current RFC.
>
> - If no scale is provided to div(), sqrt(), or pow(-$x), the result will be
> calculated to the scale of the left-hand operand, plus 10. This is the
> default behaviour in the current RFC.
>
> - Operator overloads behave the same as not specifying a scale or rounding
> mode to the corresponding method. Therefore (new BCMath\Number('20')) / (new
> BCMath\Number('3')) will result in 6.66 - an automatic scale of 10,
> and truncation of further digits.
>
>
>
> Compared to the current RFC, that means:
>
> - Remove the ability to customise "max expansion scale". For most users, this
> is a technical detail which is more confusing than useful. Users in group (b)
> will never encounter it, because they will specify scale manually; advanced
> users in group (a) may want to customise the logic in different ways anyway.
>
> - Remove the ability for a Number value to carry around its own default
> rounding mode. Users in group (a) will never use it. Users in group (b) are
> likely to want the same rounding in the whole application, but providing it
> on every call to new Number() is no easier than providing it on each
> fixed-scale calculation.
>
> - Remove the $maxExpansionScale and $roundingMode properties and constructor
> parameters.
>
> - Remove withMaxExpansionScale and withRoundMode.
>
> - Remove all the logic around propagating rounding mode and expansion scale
> between objects.
>
I have two questions.
- 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?
- 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?
> I've also noticed that the round method is currently defined as:
>
> - public function round(int $precision = 0, int $mode = PHP_ROUND_HALF_UP):
> Number {}
>
> Presumably $precision here is actually the desired scale of the result? If
> so, it should probably be named $scale, as in the rest of the interface.
>
> I realise it's called $precision in the global round() function; that's
> presumably a mistake which is now hard to fix due to named parameters.
>
> Ideally, it would be nice to have both roundToPrecision() and roundToScale(),
> but as Jordan explained, an implementation which actually calculated
> precision could be difficult and slow.
>
There is good news about this. The RFC for `bcround` does not specify the
argument names, and the implementer (me) has decided on the argument names.
And it's a change that hasn't even been merged into master yet, so I can change
the argument name without any BC break.
Regards.
Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Hi Tim,
> I don't see a change made, so perhaps I was unclear in what I said. What I
> meant was: Please add a full stub example including all the interfaces,
> properties, and methods. It's currently split across multiple code blocks and
> the interfaces are missing entirely.
>
> Example:
>
>final readonly class Number implements \Stringable {
>public string $value;
>// Further properties omitted for brevity.
>
>public function add(Number|string|int $num): Number {}
>// Further methods omitted for brevity.
>}
Ah I see. I misunderstood. I will add it when the discussion is settled.
>>> - I don't want to expand the scope of your RFC further than necessary, but
>>> for the rounding mode, I wonder if we should first add the RoundingMode
>>> enum that has been suggested during the discussion of the "Add 4 new
>>> rounding modes to round() function" RFC. It would make the type for the
>>> `Number::$roundMode` property much clearer than the current `int`. I expect
>>> the addition of such an enum to be a pretty simple RFC that would not need
>>> much discussion. I'd be happy to co-author it.
>> Oh, that's a good idea. Makes sense. I think it would be simpler to prepare
>> an RFC separate from this RFC, so I'm going to create one right away. Once
>> you have a certain amount of content, I would be happy if you could check it
>> out and make corrections if necessary.
>
> Sure, just send me an email and I'm happy to look over it before you put it
> up for discussion.
Thanks!
>>> - For `format()`, I'm not sure whether we should actually add the function.
>>> While we have number_format() for regular numbers with the same signature,
>>> it fails to account for the different language and cultures in the world.
>>> Specifically `number_format()` cannot correctly format numbers for en_IN
>>> (i.e. English in India). In India numbers are not separated every three
>>> digits, but rather the three right-most digits and then every two digits.
>>> Here's in example: 1,23,45,67,890. I believe formatting should be best left
>>> for ext/intl.
>> I'm not very familiar with ext/intl, but is there a way to format a string
>> type number without converting it to a float?
>
> It appears the underlying icu4c library supports formatting numeric strings,
> yes:
>
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1NumberFormat.html#a8ed2ca7b9a65bf08c4ef81bbf9680f0d
What I meant was that there is currently no such function in PHP. Do you think
I should propose adding it to this RFC?
>>> - I'm not sure if the priority for the rounding modes is sound. My gut
>>> feeling is that operations on numbers with different rounding modes should
>>> be disallowed or made explicit during the operation (much like the scale
>>> for a division), but I'm not an expert in designing numeric APIs, so I
>>> might be wrong here.
>> As mentioned in the RFC, the problem here is commutative calculations (add,
>> sub, mul). This means that even if specify `$roundingMode` during these
>> calculations, `$roundingMode` will not be used in these calculations.
>> Calculations that use `$roundingMode` are divs, etc. If allow
>> `$roundingMode` to be specified with add, intuitively it feels like the
>> result of add will be rounded.
>> Also, it is not possible to specify `$roundMode` in calculations using
>> operators.
>> However, if the user calculates two numbers with different rounding modes,
>> and it is intentional rather than a mistake, I can't imagine what kind of
>> result the user would want to get. Therefore, it may be better to make this
>> an error.
>> Is it appropriate to throw a value error in that case?
>
> I think making this an error would be appropriate. Generally speaking:
> Removing errors later is always possible if we find out that an operation is
> safe and well-defined. Adding an error if we find out that an operation is
> unsafe will result in breaking changes, thus we should get it right on the
> first try.
I agree, but if we adopt Rowan's suggestion this issue will go away, so if the
issue is still there when things calm down I'll add the error.
Regards.
Saki
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
> Instead, we are planning to re-propose asymmetric visibility once > property hooks are merged, as it may become more apparent why it is > useful. I was talking today to a co-worker about this internals e-mail discussion and he thought asymmetric visibility was inherent to property-hooks. He even was surprised by the possibility of having it without Aviz. He said that because he has a C# background. I really think that property hooks will highlight the benefits of Aviz. Hey, voter right beholders, please give this awesome feature a strong yes vote! -- Regards, Erick
Re: [PHP-DEV] RFC [Discussion]: array_find
On Tue, Apr 9, 2024, at 7:49 PM, Tim Düsterhus wrote: > However I'm not sure if adding new array functions piecemeal is the > right choice at this point. array_any and array_every are conceptually > very similar to array_find and are missing as well. In fact > array_any($cb, $array) = array_find($cb, $array, true) !== null and > array_every($cb, $array) = !array_any($negatedCb, $array), but it would > make sense to have them explicitly for clarity of the reader of the code. We're in a major catch-22, unfortunately. We know that collections/iterables are long overdue for a rethink, which means small fixes are just making more work for the future. Intermediate concepts like the pipe operator have been rejected. However, a full rethink is a massive undertaking, and few people want to do that given the entirely unknown odds any RFC has. And a *real* rethink doesn't make sense to do without generics, and... yeah. So I genuinely don't know what to do here, strategically. >>> 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. >> >> I like the idea, thank you! However, I am unsure whether an additional >> enum for the function would not be too much overhead. > > 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.) > Some of the array functions have paired function with a _key suffix, but > looking at the docs it appears the difference usually is that they > *operate* on the keys, instead of returning the keys. So I'm not sure > whether adding a array_find_key companion would be confusing or not. Another alternative is to always return the key, because you can trivially get the value from the key, but not vice versa. Of course, the resulting syntax for that is frequently fugly. $val = $array[array_find($db, $array)] ?? some-default; I don't have a good small-scale solution. --Larry Garfield
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
Hi Robert On Tue, Apr 9, 2024 at 9:34 PM Robert Landers wrote: > > On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield wrote: > > > > The Aviz RFC was put to a vote last year but didn't pass. > > It would be really nice if votes weren't just a yes/no vote, but > yes/needs-more-work/no vote, where needs-more-work and no are > effectively the same in terms of passing the RFC, but needs-more-work > just means there is more to do (either addressing ugly syntax or the > idea is sound, but as it says, it needs more work), and can thus be > simply revoted on after concerns are addressed -- instead of creating > a whole new RFC that needs to pass the "not too similar to other RFCs > rule." The asymmetric visibility RFC did include a poll for no votes. https://wiki.php.net/rfc/asymmetric-visibility#proposed_voting_choices > I got the impression from the Aviz discussions that most people were > against Aviz due to the syntax, not the feature itself. It would be > absolutely tragic if this failed to pass simply because people > expected Aviz here. According to the poll, syntax was one, but not the primary reason for its rejection. The primary reason was that some people don't believe the feature is necessary at all. IIRC, people were arguing that readonly covers 80% of use-cases, because it protects against writes to the property both publicly and privately. I don't agree with this viewpoint, because I think readonly is bad for ergonomics. In fact, we already had an RFC that attempted to fix clone for readonly (https://wiki.php.net/rfc/readonly_amendments) but this fix was not complete (because it's still not possible to pass values from clone to __clone). "Clone with" is another thing needed to fix this, and at this point it just feels like applying more band-aids. For DTOs, I believe value types (i.e. data classes, https://externals.io/message/122845) solve the problem of "spooky actions at a distance" in a cleaner and more ergonomic way. For services and other intentional reference types, readonly often isn't the right choice either, just to make the property not publicly writable. Asymmetric visibility would be a much more fitting choice. Anyway, we didn't include asymmetric visibility in this RFC because: * We wanted to avoid getting rejected by people who fundamentally dislike asymmetric visibility. * We didn't feel it was fair to "sneak" the feature back in through some other RFC, when it was explicitly rejected. Instead, we are planning to re-propose asymmetric visibility once property hooks are merged, as it may become more apparent why it is useful. Ilija
RFC Process (was: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks)
Hi On 4/9/24 21:32, Robert Landers wrote: The Aviz RFC was put to a vote last year but didn't pass. It would be really nice if votes weren't just a yes/no vote, but yes/needs-more-work/no vote, where needs-more-work and no are effectively the same in terms of passing the RFC, but needs-more-work just means there is more to do (either addressing ugly syntax or the idea is sound, but as it says, it needs more work), and can thus be simply revoted on after concerns are addressed -- instead of creating a whole new RFC that needs to pass the "not too similar to other RFCs rule." Re-proposing an RFC is allowed after 6 months even without substantial changes: https://github.com/php/policies/blob/main/feature-proposals.rst#resurrecting-rejected-proposals Though I'd argue that property hooks passing would be a substantial change of the broader context. -- Relatedly, I would find an official "Abstain" option useful. Any "Abstain" votes would be completely disregarded for the results, but it would allow voters to indicate that they've read the RFC, thought about it and don't sufficiently care either way to influence the results. As an RFC author I think it would be useful information to me: Did some folks not vote because they missed the RFC or because they are happy with either result? Best regards Tim Düsterhus
Re: [PHP-DEV] RFC [Discussion]: array_find
Hi On 4/7/24 21:10, Joshua Rüsweg wrote: 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) For reference: https://externals.io/message/118896#118896 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. It makes sense to me to not make `array_find` the “odd one out” and widening all the array_* functions probably would not work well, because either the Iterator is converted into array, nullifying the benefits of using an Iterator or the return type needs to be changed, making the signature confusing without generics. That said, adding a “find” function makes sense to me and the implementation looks reasonable. However I'm not sure if adding new array functions piecemeal is the right choice at this point. array_any and array_every are conceptually very similar to array_find and are missing as well. In fact array_any($cb, $array) = array_find($cb, $array, true) !== null and array_every($cb, $array) = !array_any($negatedCb, $array), but it would make sense to have them explicitly for clarity of the reader of the code. 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. I like the idea, thank you! However, I am unsure whether an additional enum for the function would not be too much overhead. 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. Some of the array functions have paired function with a _key suffix, but looking at the docs it appears the difference usually is that they *operate* on the keys, instead of returning the keys. So I'm not sure whether adding a array_find_key companion would be confusing or not. Best regards Tim Düsterhus
Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses
>
> On Mon, Apr 8, 2024, at 6:08 AM, Valentin Udaltsov wrote:
> > Hello internals,
> >
> >
> >
> > I would like to propose a syntax change for PHP 8.4 that allows to
> > immediately access instantiated objects without wrapping the expression
> > into parentheses.
> >
> >
> >
> > This was requested and discussed several times, see:
> >
> > - https://externals.io/message/66197
> >
> > - https://bugs.php.net/bug.php?id=70549
> >
> > - https://externals.io/message/101811
> >
> > - https://externals.io/message/113953
> >
> >
> >
> > Here's what you will be able to write after this change:
> >
> > ```php
> >
> > class MyClass
> >
> > {
> >
> > const CONSTANT = 'constant';
> >
> > public static $staticProperty = 'staticProperty';
> >
> > public static function staticMethod(): string { return
> 'staticMethod'; }
> >
> > public $property = 'property';
> >
> > public function method(): string { return 'method'; }
> >
> > public function __invoke(): string { return '__invoke'; }
> >
> > }
> >
> >
> >
> > var_dump(
> >
> > new MyClass()::CONSTANT,// string(8) "constant"
> >
> > new MyClass()::$staticProperty, // string(14) "staticProperty"
> >
> > new MyClass()::staticMethod(), // string(12) "staticMethod"
> >
> > new MyClass()->property,// string(8) "property"
> >
> > new MyClass()->method(),// string(6) "method"
> >
> > new MyClass()(),// string(8) "__invoke"
> >
> > );
> >
> > ```
> >
> >
> >
> > For more details see the RFC:
> https://wiki.php.net/rfc/new_without_parentheses
> >
> > Implementation: https://github.com/php/php-src/pull/13029
>
> I always thought there was some technical parser reason why this wasn't
> possible. Maybe that was true in 5.x but isn't anymore?
>
> I cannot speak to the implementation, but I'm all for the change itself.
>
> --Larry Garfield
>
Hi, Larry! The grammar is compiled with no warnings, so it is definitely
possible now. I also added a lot of tests that guarantee that existing
behaviour is preserved and new syntax works as expected.
Marco, Bilge, Levi, Larry, thank you for your positive feedback on the RFC.
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield wrote: > > On Tue, Apr 9, 2024, at 4:07 PM, Levi Morrison wrote: > > > I was playing around with 3v4l.org. Is the implementation up-to-date there? > > > > I don't have any hard objections at the moment, but after playing with > > it for a while, I do kind of wonder if it's a lot of complexity for > > what is effectively a niche feature because: > > > > 1. It does not support asymmetric visibility for get/set. Having a > > public getter and private setter seems really natural. > > Aviz is a separate RFC, for reasons we've covered before: They're actually > two separate features that do not depend on each other, so we split them up > to help reduce RFC size (something RFC authors are often encouraged to do). > The Aviz RFC was put to a vote last year but didn't pass. If hooks pass, we > do want to revisit aviz and bring it to another vote, as the argument may be > stronger now with hooks in place. > > > 2. You can't access accessors for "siblings". > > If a use case for this is found, that should be addable in a future RFC with > no notable BC break. (Assuming a syntax of self::$otherProp::get() or > similar, it would only have the same slight edge case as the > parent::$thisProp::get() has, as documented in the RFC. As we've decided > that is too edge-casey to care about here, presumably the same would hold > true for such an follow-up.) > > > 3. You can't do by-reference set (important for arrays). > > This is due to logical limitations in the context. By-ref set means set > hooks don't get called. So we can either block by-ref manipulation when a > set hook is defined, or we can make set hooks easily-bypassable suggestions > at best. We have not found any way around that decision. (And as noted in > the RFC, this problem is already present if just using methods. It's not a > new issue.) > > Please note that *the scope of what is blocked has been reduced considerably > from earlier versions of the RFC!* The only invalid combination is /set > on a backed property, because of the issue above. Writing to an array > returned from a hook is allowed in certain circumstances, namely, if it was > returned by and there is no set. > > So we're only preventing the narrowest set of operations we reasonably can, > without hamstringing the concept of a set hook in the first place, and we > don't believe there is any logical approach that would allow more. If in the > future someone can come up with an approach that would work, it would likely > be addable in a BC way. > > > 4. You can't satisfy a parent's readonly property with a getter in a child. > > In the last week or two we've figured out a situation where we may be able to > allow this; iff the child getter works by reading the parent's value, then it > would *probably* still be able to satisfy readonly's guarantees. We haven't > tried implementing it yet as the RFC is large enough as is, but it's possible > that could be added in the future. The main issue is that there's no way to > fully guarantee that a get hook on a readonly property is idemopotent, the > way a bare readonly property is. (It's not a lack of desire to support it, > just the logical issues in ensuring different features' invariants are > maintained.) > > Note that it's still unclear what set from a child set hook should do, given > that readonly properties are also silently private-set, even if the property > itself is protected or public. Potentially we could mandate that a child set > MUST use parent::$prop::set(), so the actual write is technically in the > parent class. I've noted this before as a design flaw in readonly that > really needs to be corrected, but that's not a job for this RFC. (We > actually had a solution in the aviz RFC, but people pushed back on it so we > had to remove it.) > > > Now, points 2 through 4 are fairly minor and niche by themselves, but > > if we take all these restrictions as a whole... I'm a bit worried. > > Hopefully the above comments make you less worried. :-) > > --Larry Garfield Off-topic random thought: > The Aviz RFC was put to a vote last year but didn't pass. It would be really nice if votes weren't just a yes/no vote, but yes/needs-more-work/no vote, where needs-more-work and no are effectively the same in terms of passing the RFC, but needs-more-work just means there is more to do (either addressing ugly syntax or the idea is sound, but as it says, it needs more work), and can thus be simply revoted on after concerns are addressed -- instead of creating a whole new RFC that needs to pass the "not too similar to other RFCs rule." I got the impression from the Aviz discussions that most people were against Aviz due to the syntax, not the feature itself. It would be absolutely tragic if this failed to pass simply because people expected Aviz here. Robert Landers Software Engineer Utrecht NL
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
On 24/03/2024 13:13, Saki Takamachi wrote:
https://wiki.php.net/rfc/support_object_type_in_bcmath
Based on the various discussions we've been having, I'd like to propose
a simplified handling of "scale".
I think there are two groups of users we are trying to help:
a) Users who want an "infinite" scale, and will round manually when
absolutely necessary, e.g. for display. The scale can't actually be
infinite in the case of calculations like 1/3, so they need some safe
cut-off.
b) Users who want to perform operations on a fixed scale, with
configurable rounding, e.g. for e-commerce pricing. They are not
interested in any larger scale, except possibly in some intermediate
calculations, when they want the same as group (a).
I propose:
- The constructor accepts string|int $num only.
- All operations accept an optional scale and rounding mode.
- If no rounding mode is provided, the default behaviour is to truncate.
This means that (new BCMath\Number('20'))->div(3, 5) has the same result
as bcdiv('20', '3', 5) which is 6.6
- If a rounding mode is provided, the object transparently calculates
one extra digit of scale, then rounds according to the specified mode.
- If no scale is provided, most operations will automatically calculate
the required scale, e.g. add will use the larger of the two scales. This
is the same as the current RFC.
- If no scale is provided to div(), sqrt(), or pow(-$x), the result will
be calculated to the scale of the left-hand operand, plus 10. This is
the default behaviour in the current RFC.
- Operator overloads behave the same as not specifying a scale or
rounding mode to the corresponding method. Therefore (new
BCMath\Number('20')) / (new BCMath\Number('3')) will result in
6.66 - an automatic scale of 10, and truncation of further digits.
Compared to the current RFC, that means:
- Remove the ability to customise "max expansion scale". For most users,
this is a technical detail which is more confusing than useful. Users in
group (b) will never encounter it, because they will specify scale
manually; advanced users in group (a) may want to customise the logic in
different ways anyway.
- Remove the ability for a Number value to carry around its own default
rounding mode. Users in group (a) will never use it. Users in group (b)
are likely to want the same rounding in the whole application, but
providing it on every call to new Number() is no easier than providing
it on each fixed-scale calculation.
- Remove the $maxExpansionScale and $roundingMode properties and
constructor parameters.
- Remove withMaxExpansionScale and withRoundMode.
- Remove all the logic around propagating rounding mode and expansion
scale between objects.
I've also noticed that the round method is currently defined as:
- public function round(int $precision = 0, int $mode =
PHP_ROUND_HALF_UP): Number {}
Presumably $precision here is actually the desired scale of the result?
If so, it should probably be named $scale, as in the rest of the interface.
I realise it's called $precision in the global round() function; that's
presumably a mistake which is now hard to fix due to named parameters.
Ideally, it would be nice to have both roundToPrecision() and
roundToScale(), but as Jordan explained, an implementation which
actually calculated precision could be difficult and slow.
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Hi
On 4/8/24 02:08, Saki Takamachi wrote:
- The full “stub” should probably include an explicit "implements Stringable"
for clarity.
Agree. I describe it explicitly during implementation.
I don't see a change made, so perhaps I was unclear in what I said. What
I meant was: Please add a full stub example including all the
interfaces, properties, and methods. It's currently split across
multiple code blocks and the interfaces are missing entirely.
Example:
final readonly class Number implements \Stringable {
public string $value;
// Further properties omitted for brevity.
public function add(Number|string|int $num): Number {}
// Further methods omitted for brevity.
}
- I don't want to expand the scope of your RFC further than necessary, but for the
rounding mode, I wonder if we should first add the RoundingMode enum that has been
suggested during the discussion of the "Add 4 new rounding modes to round()
function" RFC. It would make the type for the `Number::$roundMode` property much
clearer than the current `int`. I expect the addition of such an enum to be a pretty
simple RFC that would not need much discussion. I'd be happy to co-author it.
Oh, that's a good idea. Makes sense. I think it would be simpler to prepare an
RFC separate from this RFC, so I'm going to create one right away. Once you
have a certain amount of content, I would be happy if you could check it out
and make corrections if necessary.
Sure, just send me an email and I'm happy to look over it before you put
it up for discussion.
- For `format()`, I'm not sure whether we should actually add the function.
While we have number_format() for regular numbers with the same signature, it
fails to account for the different language and cultures in the world.
Specifically `number_format()` cannot correctly format numbers for en_IN (i.e.
English in India). In India numbers are not separated every three digits, but
rather the three right-most digits and then every two digits. Here's in
example: 1,23,45,67,890. I believe formatting should be best left for ext/intl.
I'm not very familiar with ext/intl, but is there a way to format a string type
number without converting it to a float?
It appears the underlying icu4c library supports formatting numeric
strings, yes:
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1NumberFormat.html#a8ed2ca7b9a65bf08c4ef81bbf9680f0d
- I'm not sure if the priority for the rounding modes is sound. My gut feeling
is that operations on numbers with different rounding modes should be
disallowed or made explicit during the operation (much like the scale for a
division), but I'm not an expert in designing numeric APIs, so I might be wrong
here.
As mentioned in the RFC, the problem here is commutative calculations (add,
sub, mul). This means that even if specify `$roundingMode` during these
calculations, `$roundingMode` will not be used in these calculations.
Calculations that use `$roundingMode` are divs, etc. If allow `$roundingMode`
to be specified with add, intuitively it feels like the result of add will be
rounded.
Also, it is not possible to specify `$roundMode` in calculations using
operators.
However, if the user calculates two numbers with different rounding modes, and
it is intentional rather than a mistake, I can't imagine what kind of result
the user would want to get. Therefore, it may be better to make this an error.
Is it appropriate to throw a value error in that case?
I think making this an error would be appropriate. Generally speaking:
Removing errors later is always possible if we find out that an
operation is safe and well-defined. Adding an error if we find out that
an operation is unsafe will result in breaking changes, thus we should
get it right on the first try.
Best regards
Tim Düsterhus
Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions
Hi On 4/8/24 14:00, Pablo Rauzy wrote: So what should be done to move forward with this? Should the old RFC on strict argument count be revived? Or should a new RFC proposal be written? If so, should it contain an It should be a new "v2" RFC. The old RFC already contains a vote, thus editing it would change historic votes. approval voting (where voters can select any number of candidates), prior to the RFC proposal vote itself, to decide if the change should be: strict argument count, using the void keyword to explicitely stop the argument list, or using a #[Nonvariadic] attribute? And RFC needs a clear primary vote. I believe the options you mentioned are too different to usefully be voted on with a single primary vote + a "tie breaker". I believe it should be a simple opinionated RFC. Should it not pass, follow-up RFCs for the alternative options can be proposed if it is desired. Best regards Tim Düsterhus
Re: [PHP-DEV] Requiring GPG Commit Signing
Hi On 4/9/24 13:02, Derick Rethans wrote: It seems that most of the reply to this was positive, although with the realisation that it wouldn't be a panacea. I will therefore propose a minimalistic RFC to create this requirement to sign commits to all branches, in the next few days. I probably would have prefered requiring *GPG* signing (due to a web of trust), but GitHub's requirement isn't that granuar (it's either SSG+GPG, or nothing). Any other opinions, I'd be delighted to hear them. Web of trust for PGP is effectively dead since https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f. Requiring any type of signature on the commits is fine. The distinct public keys will build reputation on their own by making good commits. More signatures is certainly better than fewer. In fact I would find it sufficient to just *strongly encourage* the regular committers to set up signing, even without actually enforcing it on GitHub. Best regards Tim Düsterhus
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
On Tue, Apr 9, 2024, at 4:07 PM, Levi Morrison wrote: > I was playing around with 3v4l.org. Is the implementation up-to-date there? > > I don't have any hard objections at the moment, but after playing with > it for a while, I do kind of wonder if it's a lot of complexity for > what is effectively a niche feature because: > > 1. It does not support asymmetric visibility for get/set. Having a > public getter and private setter seems really natural. Aviz is a separate RFC, for reasons we've covered before: They're actually two separate features that do not depend on each other, so we split them up to help reduce RFC size (something RFC authors are often encouraged to do). The Aviz RFC was put to a vote last year but didn't pass. If hooks pass, we do want to revisit aviz and bring it to another vote, as the argument may be stronger now with hooks in place. > 2. You can't access accessors for "siblings". If a use case for this is found, that should be addable in a future RFC with no notable BC break. (Assuming a syntax of self::$otherProp::get() or similar, it would only have the same slight edge case as the parent::$thisProp::get() has, as documented in the RFC. As we've decided that is too edge-casey to care about here, presumably the same would hold true for such an follow-up.) > 3. You can't do by-reference set (important for arrays). This is due to logical limitations in the context. By-ref set means set hooks don't get called. So we can either block by-ref manipulation when a set hook is defined, or we can make set hooks easily-bypassable suggestions at best. We have not found any way around that decision. (And as noted in the RFC, this problem is already present if just using methods. It's not a new issue.) Please note that *the scope of what is blocked has been reduced considerably from earlier versions of the RFC!* The only invalid combination is /set on a backed property, because of the issue above. Writing to an array returned from a hook is allowed in certain circumstances, namely, if it was returned by and there is no set. So we're only preventing the narrowest set of operations we reasonably can, without hamstringing the concept of a set hook in the first place, and we don't believe there is any logical approach that would allow more. If in the future someone can come up with an approach that would work, it would likely be addable in a BC way. > 4. You can't satisfy a parent's readonly property with a getter in a child. In the last week or two we've figured out a situation where we may be able to allow this; iff the child getter works by reading the parent's value, then it would *probably* still be able to satisfy readonly's guarantees. We haven't tried implementing it yet as the RFC is large enough as is, but it's possible that could be added in the future. The main issue is that there's no way to fully guarantee that a get hook on a readonly property is idemopotent, the way a bare readonly property is. (It's not a lack of desire to support it, just the logical issues in ensuring different features' invariants are maintained.) Note that it's still unclear what set from a child set hook should do, given that readonly properties are also silently private-set, even if the property itself is protected or public. Potentially we could mandate that a child set MUST use parent::$prop::set(), so the actual write is technically in the parent class. I've noted this before as a design flaw in readonly that really needs to be corrected, but that's not a job for this RFC. (We actually had a solution in the aviz RFC, but people pushed back on it so we had to remove it.) > Now, points 2 through 4 are fairly minor and niche by themselves, but > if we take all these restrictions as a whole... I'm a bit worried. Hopefully the above comments make you less worried. :-) --Larry Garfield
Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses
I haven't verified the implementation, but as long as there really aren't backwards compatibility issues for correct code, then this would be a nice quality of life improvement.
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
On Mon, Apr 8, 2024 at 3:42 PM 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 I was playing around with 3v4l.org. Is the implementation up-to-date there? I don't have any hard objections at the moment, but after playing with it for a while, I do kind of wonder if it's a lot of complexity for what is effectively a niche feature because: 1. It does not support asymmetric visibility for get/set. Having a public getter and private setter seems really natural. 2. You can't access accessors for "siblings". 3. You can't do by-reference set (important for arrays). 4. You can't satisfy a parent's readonly property with a getter in a child. Now, points 2 through 4 are fairly minor and niche by themselves, but if we take all these restrictions as a whole... I'm a bit worried. I also don't like the syntax. I can ignore this for the vote and still vote yes because I don't like the syntax, but with these other things... I'm worried.
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Tue, Apr 9, 2024 at 7:52 PM Derick Rethans wrote: > Adding a new native type to PHP will create a large change. Not only is > it "just" adding a new native type, it also means all of the conversions > between types need to be added. This is not a small task. I understand this :) > If you want to use arbitrary precision natives, then a precision and > scale as defined in php.ini defeats the purpose. Every installation can > then potentially calculate things in a different way. > > The only way how to prevent that, is to have *actual* Decimal type, such > as the Decimal type in MongoDB uses (the IEEE 754 decimal128 type): > > - > https://www.mongodb.com/docs/mongodb-shell/reference/data-types/#std-label-shell-type-decimal > - https://en.wikipedia.org/wiki/Decimal128_floating-point_format If PHP core experts think that 128-bit decimal will cover the vast majority of cases and is worth implementing, I'm totally for it. If we can implement something standardized then fine. The current thread is not an RFC candidate, but a kinda discussion board to formulate the design principles and strategy. On another note, is it possible to make zval variable size - 64 or 128 bits? So the 128-bit decimal can be a struct that will be held in the stack instead of pointer manipulations. Can it be achieved with the help of macroses? -- Best, Alexander
Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses
On Mon, Apr 8, 2024, at 6:08 AM, Valentin Udaltsov wrote:
> Hello internals,
>
>
>
> I would like to propose a syntax change for PHP 8.4 that allows to
> immediately access instantiated objects without wrapping the expression
> into parentheses.
>
>
>
> This was requested and discussed several times, see:
>
> - https://externals.io/message/66197
>
> - https://bugs.php.net/bug.php?id=70549
>
> - https://externals.io/message/101811
>
> - https://externals.io/message/113953
>
>
>
> Here's what you will be able to write after this change:
>
> ```php
>
> class MyClass
>
> {
>
> const CONSTANT = 'constant';
>
> public static $staticProperty = 'staticProperty';
>
> public static function staticMethod(): string { return 'staticMethod'; }
>
> public $property = 'property';
>
> public function method(): string { return 'method'; }
>
> public function __invoke(): string { return '__invoke'; }
>
> }
>
>
>
> var_dump(
>
> new MyClass()::CONSTANT,// string(8) "constant"
>
> new MyClass()::$staticProperty, // string(14) "staticProperty"
>
> new MyClass()::staticMethod(), // string(12) "staticMethod"
>
> new MyClass()->property,// string(8) "property"
>
> new MyClass()->method(),// string(6) "method"
>
> new MyClass()(),// string(8) "__invoke"
>
> );
>
> ```
>
>
>
> For more details see the RFC: https://wiki.php.net/rfc/new_without_parentheses
>
> Implementation: https://github.com/php/php-src/pull/13029
I always thought there was some technical parser reason why this wasn't
possible. Maybe that was true in 5.x but isn't anymore?
I cannot speak to the implementation, but I'm all for the change itself.
--Larry Garfield
Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
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
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
> - Use precision instead of scale > - The default maximum precision is 20 digits > - The default rounding mode is HALF_UP > - The constructor takes only $num arguments > - The method can optionally specify any precision and any rounding mode when > calculating > - Operators always use only default values in their calculations Ah, that takes away the benefit of arbitrary precision... Maybe I'm sleepy, forget about this. Regards. Saki
[PHP-DEV] [RFC] [Vote] Deprecate GET/POST sessions
Hi Internals, I have opened the vote on https://wiki.php.net/rfc/deprecate-get-post-sessions It will close on 2024-04-23 Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Hi, To be honest, I think it would be much easier to use if we could make it look like this: - Use precision instead of scale - The default maximum precision is 20 digits - The default rounding mode is HALF_UP - The constructor takes only $num arguments - The method can optionally specify any precision and any rounding mode when calculating - Operators always use only default values in their calculations However, BCMath has worked with scale for a long time, so I'm not sure that introducing precision behavior here would be of any benefit to users... Regards. Saki
Re: [PHP-DEV] Requiring GPG Commit Signing
On Tue, 2 Apr 2024, Derick Rethans wrote: > What do y'all think about requiring GPG signed commits for the php-src > repository? > > I had a look, and this is also something we can enforce through GitHub > as well (by using branch protections). It seems that most of the reply to this was positive, although with the realisation that it wouldn't be a panacea. I will therefore propose a minimalistic RFC to create this requirement to sign commits to all branches, in the next few days. I probably would have prefered requiring *GPG* signing (due to a web of trust), but GitHub's requirement isn't that granuar (it's either SSG+GPG, or nothing). Any other opinions, I'd be delighted to hear them. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Wed, 3 Apr 2024, Jordan LeDoux wrote: > On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP] > wrote: > > > > > Where things get more complicated is with *fixed-precision* decimals, > > which is what is generally wanted for something like money. What is the > > correct result of decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)? > > decimal(0.51, 2)? decimal (0.52, 2)? an error? And what about decimal(10) / > > 3? > > > > If you stick to functions / methods, this is slightly less of an issue, > > because you can have decimal(1.03, 2)->dividedBy(2, RoundingMode::DOWN) == > > decimal(0.51, 2); or decimal(1.03, 2)->split(2) == [ decimal(0.52, 2), > > decimal(0.51, 2) ] Example names taken directly from the brick/money > > package. > > > > At that point, backwards compatibility is less of an issue as well: make > > the new functions convenient to use, but distinct from the existing ones > > > I came back to this discussion after my last reply on the BCMath as an > object thread, because we went through a very similar discussion there with > regard to operators. > > I think that, roughly, the fixed precision should be defined on the scalar > itself: > > 1.234_d3 > > 1.234 is the value, _d makes it a decimal type, and 3 shows that this value > has a precision of 3. (Actually, it has a SCALE of 3, since precision is > significant digits, and also includes the integer portion). But when it > comes to fixed-precision values, it should follow rules very similar to > those we discussed in the BCMath thread: Woound't it be much better to capture this complex information in an Object, and then allow operators on this? Like... Saki was pretty much suggesting with her BCMatch/Number class RFC? I can't imagine people looking at code understanding a syntax like this right away, let alone of what it all means. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Thu, 7 Dec 2023, Alex Pravdin wrote: > Accounting for all of the above, I suggest adding a native numeric > scalar arbitrary precision type called "decimal". Below are the > preliminary requirements for implementation. Adding a new native type to PHP will create a large change. Not only is it "just" adding a new native type, it also means all of the conversions between types need to be added. This is not a small task. > Decimal values can be created from literals by specifying a modifier or using > the (decimal) typecast: > > $v = 0.2d; > $v = (decimal) 0.2; // Creates a decimal value without intermediary float > > It uses the precision and scale defined in php.ini. If you want to use arbitrary precision natives, then a precision and scale as defined in php.ini defeats the purpose. Every installation can then potentially calculate things in a different way. The only way how to prevent that, is to have *actual* Decimal type, such as the Decimal type in MongoDB uses (the IEEE 754 decimal128 type): - https://www.mongodb.com/docs/mongodb-shell/reference/data-types/#std-label-shell-type-decimal - https://en.wikipedia.org/wiki/Decimal128_floating-point_format cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social
[PHP-DEV] [VOTE] [RFC] Release cycle update, take #2
Hi, there have been no further comments on the release cycle update RFC thread, so I'm hereby opening the RFC for voting. Voting will end on Monday April 29th, at noon UTC (20 days, instead of the required minimum of 14): https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social
Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both?
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]
