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
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
-
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
>
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
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
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
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
>
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
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
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?
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
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
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
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
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
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
>
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 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 *
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
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
20 matches
Mail list logo
