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.ph
Hi Rowan,
> Well, that's the original question: are they actually different purposes,
> from the point of view of a user?
The purpose of both is different from a detailed perspective. Addition of
native types and addition of OOP API. But if think about the purpose from a
broader perspective, i
Hi Rowan
> As I replied to Jordan, I don't see why this is connected to "scalar" vs
> "object" types at all. An object - particularly an immutable one - is just a
> way of declaring a type, and some syntax for operations on that type. There's
> really no difference at all between these:
>
> $h
Hi Tim,
>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.
Once **I** have
Hi Tim,
> - The namespace is inconsistently referred to as "BCMath" and "BcMath",
> please check the entire RFC to unify the casing.
Thanks, I fixed it.
> - The full “stub” should probably include an explicit "implements Stringable"
> for clarity.
Agree. I describe it explicitly during imple
On Sun, Apr 7, 2024 at 2:45 PM Rowan Tommins [IMSoP]
wrote:
> On 07/04/2024 20:55, Jordan LeDoux wrote:
>
> > I have been doing small bits of work, research, and investigation into
> > an MPDec or MPFR implementation for years, and I'm likely to continue
> > doing my research on that regardless o
On 07/04/2024 20:55, Jordan LeDoux wrote:
I have been doing small bits of work, research, and investigation into
an MPDec or MPFR implementation for years, and I'm likely to continue
doing my research on that regardless of whatever is discussed in this
thread.
I absolutely encourage you to
On Sun, Apr 7, 2024 at 8:27 AM Rowan Tommins [IMSoP]
wrote:
>
>
> On 7 April 2024 15:38:04 BST, Saki Takamachi wrote:
> >> In other words, looking at how the efforts overlap doesn't have to mean
> abandoning one of them, it can mean finding how one can benefit the other.
> >
> >I agree that the
Hi
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
On 07/04/2024 14:27, Saki Takamachi wrote:
If we really wanted decimal to be a native type, then the rounding
mode and scale behavior should be completely fixed and not user
selectable. If not, decimal should be implemented as a class.
As I replied to Jordan, I don't see why this is connected
On 07/04/2024 18:09, Tim Düsterhus wrote:
- 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 ex
Hi
On 4/6/24 17:07, Saki Takamachi wrote:
To you all:
The discussions thus far have been reflected in the RFC. I would be very happy if you
could check it out. (Thanks Tim, the tag is very easy to read.)
https://wiki.php.net/rfc/support_object_type_in_bcmath
Thank you for the updates. Some r
Hi
On 3/28/24 14:30, Saki Takamachi wrote:
Thanks. Sorry, I meant "If I create dedicated exception classes, do I need
separate classes for each type of error?” I couldn't write it well in English.
To answer this question, even if it is not necessary after all:
You should create separate clas
On 7 April 2024 15:38:04 BST, Saki Takamachi wrote:
>> In other words, looking at how the efforts overlap doesn't have to mean
>> abandoning one of them, it can mean finding how one can benefit the other.
>
>I agree that the essence of the debate is as you say.
>However, an argument must alway
Hi Rowan,
> While I appreciate that that was the original aim, a lot of the discussion at
> the moment isn't really about BCMath at all, it's about how to define a
> fixed-precision number type. For instance, how to specify precision and
> rounding for operations like division. I haven't seen a
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 ot
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.
Y
Hi
On 4/7/24 06:37, Juliette Reinders Folmer wrote:
I forwarded your questions from above verbatim to Nicolas and this was
his response (also quoted verbatim):
Thank you.
> So, this one is interesting.
> Sure, if you look at these extremes, stringing them back to back all
in a uppercase,
On 7 April 2024 11:44:22 BST, Saki Takamachi wrote:
>I don't think the two threads can be combined because they have different
>goals. If one side of the argument was, "How about to add BCMath?" then
>perhaps we should merge the discussion. But BCMath already exists and the
>agenda is to add
Hi,
> What I'm saying is that $x / 2 doesn't have a good answer if $x is a
> fixed-precision number which can't be divided by 2 without exceeding that
> precision. You need a third operand, the rounding mode, so you can't write it
> as a binary operator, and need some kind of function like decim
Hi Rowan,
>> On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
>>
>> Internals is just volunteers. The people working on BCMath are doing that
>> because they want to, the people working on scalar decimal stuff are doing
>> that because they want to, and there's no project planning to tell one
On 07/04/2024 11:07, Rowan Tommins [IMSoP] wrote:
On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
Internals is just volunteers. The people working on BCMath are doing that
because they want to, the people working on scalar decimal stuff are doing
that because they want to, and there's no p
On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
>Internals is just volunteers. The people working on BCMath are doing that
>because they want to, the people working on scalar decimal stuff are doing
>that because they want to, and there's no project planning to tell one
>group to stop. That
23 matches
Mail list logo
