Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123010
Content-Type: multipart/alternative;
 boundary="------------0OysqPNoCnUbb5U1cAuAlviC"
Message-ID: <dd46e324-c1db-4c41-9cc8-0257ff511e07@redmagic.org.uk>
Date: Sun, 7 Apr 2024 11:40:08 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Native decimal scalar support and object types in
 BcMath - do we want both?
To: internals@lists.php.net
References: <37e79b28-ac4d-4413-9df8-54a123dfd1e3@redmagic.org.uk>
 <CAMrTa2HX2dCEr4uA5OumqwVbwd8E=upqiipFT_84b1J1HWOSVw@mail.gmail.com>
 <240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk>
Content-Language: en-US
In-Reply-To: <240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk>
From: barney@redmagic.org.uk (Barney Laurance)

This is a multi-part message in MIME format.
--------------0OysqPNoCnUbb5U1cAuAlviC
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/04/2024 11:07, Rowan Tommins [IMSoP] wrote:
>
> On 7 April 2024 01:32:29 BST, Jordan LeDoux<jordan.ledoux@gmail.com>  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's not how internals works (to the extent it works).
> I kind of disagree. You're absolutely right the detailed effort is almost always put in by people working on things that interest them, and I want to make clear up front that I'm extremely grateful to the amount of effort people do volunteer, given how few are paid to work on any of this.
>
> However, the goal of the Internals community as a whole is to choose what changes to make to a language which is used by millions of people. That absolutely involves project planning, because there isn't a marketplace of PHP forks with different competing features, and once a feature is added it's very hard to remove it or change its design.
>
> If - and I stress I'm not saying this is true - IF these two features have such an overlap that we would only want to release one, then we shouldn't just accept whichever is ready first, we should choose which is the better solution overall. And if that was the case, why would we wait for a polished implementation of both, then tell one group of volunteers that all their hard work had been a waste of time?
>
> So I think the question is very valid: do these two features have distinct use cases, such that even if we had one, we would still want to spend time on the other? Or, should we decide a strategy for both groups to work together towards a single goal?
>
> That's not about "telling one group to stop", it's about working together for the benefit of both users and the people volunteering their effort, to whom I am extremely grateful.


Yes, I was going to say the same thing as Rowan. But also Jordan has 
shown that there's at least one advantage to each proposal - one would 
be much more performant, one would might be releasable a lot sooner. 
That's a possible reason to keep both.
--------------0OysqPNoCnUbb5U1cAuAlviC
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 07/04/2024 11:07, Rowan Tommins
      [IMSoP] wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:240D79D1-708D-45A7-9989-D28893955D6E@rwec.co.uk">
      <pre class="moz-quote-pre" wrap="">

On 7 April 2024 01:32:29 BST, Jordan LeDoux <a class="moz-txt-link-rfc2396E" href="mailto:jordan.ledoux@gmail.com">&lt;jordan.ledoux@gmail.com&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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's not how internals works (to the extent it works).
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I kind of disagree. You're absolutely right the detailed effort is almost always put in by people working on things that interest them, and I want to make clear up front that I'm extremely grateful to the amount of effort people do volunteer, given how few are paid to work on any of this.

However, the goal of the Internals community as a whole is to choose what changes to make to a language which is used by millions of people. That absolutely involves project planning, because there isn't a marketplace of PHP forks with different competing features, and once a feature is added it's very hard to remove it or change its design.

If - and I stress I'm not saying this is true - IF these two features have such an overlap that we would only want to release one, then we shouldn't just accept whichever is ready first, we should choose which is the better solution overall. And if that was the case, why would we wait for a polished implementation of both, then tell one group of volunteers that all their hard work had been a waste of time?

So I think the question is very valid: do these two features have distinct use cases, such that even if we had one, we would still want to spend time on the other? Or, should we decide a strategy for both groups to work together towards a single goal?

That's not about "telling one group to stop", it's about working together for the benefit of both users and the people volunteering their effort, to whom I am extremely grateful.</pre>
    </blockquote>
    <p><br>
    </p>
    <span style="white-space: pre-wrap">Yes, I was going to say the same thing as Rowan. But also Jordan has shown that there's at least one advantage to each proposal - one would be much more performant, one would might be releasable a lot sooner. That's a possible reason to keep both. 
</span>
  </body>
</html>

--------------0OysqPNoCnUbb5U1cAuAlviC--