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 li
Hi Jordan,
> To me, while being 100x to 1000x more performant at arithmetic is certainly
> reason enough on its own, the fact that MPFR (for example) has C
> implementations for more complex operations that can be utilized is the real
> selling point. The ext-stats extension hasn't been maintai
Mainly review and approve pull request to mbstring extension.
(probably everything related to Unicode and other character encoding)
Alex Dowad (alexdowad) suggested that give to me.
https://github.com/php/php-src/pull/13906#issuecomment-2041585626
--
---
Yuya Hamada (tekim
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
Hi Valentin,
You don't need me to tell you how popular your PR is, since it's the
single most emoji'd open PR by a wide margin, but this is something that
has bugged me since the parser improvements in 5.4. I even remember
asking Nikita if it was possible to not have to wrap `new Class` in
pa
On Mon, Apr 8, 2024 at 12:23 PM Rowan Tommins [IMSoP]
wrote:
>
> As I mentioned in the discussion about a "scalar arbitrary precision
> type", the idea of a scalar in this meaning is a non-trivial challenge, as
> the zval can only store a value that is treated in this way of 64 bits or
> smaller.
On 07/04/2024 23:50, Jordan LeDoux wrote:
By a "scalar" value I mean a value that has the same semantics for
reading, writing, copying, passing-by-value, passing-by-reference, and
passing-by-pointer (how objects behave) as the integer, float, or
boolean types.
Right, in that case, it might b
On Mon, Apr 8, 2024, 16:40 Rowan Tommins [IMSoP]
wrote:
> On Mon, 8 Apr 2024, at 13:42, Arvids Godjuks wrote:
>
> The ini setting I was considering would function similarly to what it does
> for floats right now - I assume it changes the exponent, thereby increasing
> their precision but reducing
On Mon, 8 Apr 2024, at 13:42, Arvids Godjuks wrote:
> The ini setting I was considering would function similarly to what it does
> for floats right now - I assume it changes the exponent, thereby increasing
> their precision but reducing the integer range they can cover.
If you're thinking of th
On Mon, 8 Apr 2024 at 14:33, Barney Laurance wrote:
> On 2024-04-08 12:17, Arvids Godjuks wrote:
>
> > Why not have decimal be represented as 2 64-bit ints at the engine
> > level
>
> Just to clarify this point, what's the formula to convert back and
> forth between a decimal and two integers? Ar
Hello all,
Le 05/04/2024 à 15:53, Larry Garfield a écrit :
On Thu, Apr 4, 2024, at 9:27 PM, Ilija Tovilo wrote:
On Thu, Apr 4, 2024 at 5:58 PM Tim Düsterhus wrote:
On 4/4/24 16:36, Pablo Rauzy wrote:
I strongly agree in theory, but this could break existing code, and
moreover such a proposal
On Mon, Apr 8, 2024 at 3:11 AM Valentin Udaltsov <
udaltsov.valen...@gmail.com> 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
On 2024-04-08 12:17, Arvids Godjuks wrote:
Why not have decimal be represented as 2 64-bit ints at the engine
level
Just to clarify this point, what's the formula to convert back and
forth between a decimal and two integers? Are you thinking like
scientific notation: decimal = coefficient *
Hello everyone, I've been following the discussion threads and forming my
own opinion to share since I have done a bunch of financial stuff
throughout my career: I did the integers only at the application level and
DECIMAL(20,8) in the database due to handling Bitcoin, Litecoin, etc.
My feeling on
On Tue, Mar 19, 2024 at 5:35 AM Rowan Tommins [IMSoP]
wrote:
> I think a reasonable number of people do share the sentiment that having two
> separate modes was a mistake; and neither mode is actually perfect. It's not
> about "making it on by default", it's about coming up with a unified
> be
Hi Rowan,
> Again, I don't think "has more than one attribute" is the same as "feel
> almost like objects". But we're just getting further away from the current
> discussion, I think.
> The proposed class is called BCMath\Number, which implies that every instance
> of that class represents a n
On 8 April 2024 10:12:31 BST, Saki Takamachi wrote:
>
>I don't see any point in "scalar types" that feel almost like objects, because
>it just feels like you're manipulating objects with procedural functions. Why
>not just use objects instead?
Again, I don't think "has more than one attribut
On Mon, Apr 8, 2024 at 5:06 PM Rowan Tommins [IMSoP]
wrote:
> If we ever do want to make decimals a native type, we would need some way to
> initialise a decimal value, since 1.2 will initialise a float.
My original suggestion was:
- Add "default decimal" mode with the "declare" statement in t
Hi Rowan,
> Again, that only seems related to objects because that's what you're used to
> in PHP, and even then you're overlooking an obvious exception: array(1, 2)
Arrays are a bad example here because their contents are themselves values. For
example, it would make sense as an example if th
On 8 April 2024 01:34:45 BST, Saki Takamachi wrote:
>
> I'm making these opinions from an API design perspective. How the data is
> held internally is irrelevant. zval has a lot of data other than values. What
> I want to say is that if multiple types of parameters are required for
> initial
20 matches
Mail list logo
