Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116977
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4585-ga9d9773056-fm-20220113.001-ga9d97730
Mime-Version: 1.0
Message-ID: <5abf4ffb-1a4a-4623-a1a4-08032f631906@www.fastmail.com>
In-Reply-To: 
 <DM6PR14MB4155903D88D662A3BD756545F9289@DM6PR14MB4155.namprd14.prod.outlook.com>
References: 
 <DM6PR07MB66185E23B803C5E5BF858B30F9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <DM6PR14MB41556131E6A9D7812854AA75F9269@DM6PR14MB4155.namprd14.prod.outlook.com>
 <1c9e79d5-fd79-45a8-9c77-4228d770062d@www.fastmail.com>
 <DM6PR14MB4155E8620E5907BDA2320B7EF9279@DM6PR14MB4155.namprd14.prod.outlook.com>
 <3ae1a3f5-b4ea-40a0-b03f-3fa69ed6b9d2@www.fastmail.com>
 <DM6PR14MB4155903D88D662A3BD756545F9289@DM6PR14MB4155.namprd14.prod.outlook.com>
Date: Thu, 03 Feb 2022 09:19:53 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Adding `final class Deque` to PHP
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Feb 2, 2022, at 9:14 PM, tyson andre wrote:
> Hi Larry Garfield,
>
>> >> Returning $this would resolve that, I think.=C2=A0 (Making it retu=
rn a new, immutable copy of the Deque would be even nicer, but I realize=
 that's probably not an argument I'm going to win at this point on this =
RFC.)
>> >
>> > Technically, you still can have single-expression usages in
>> > readable/unreadable ways
>> >
>> > - `[$deque->shift('value'), $deque][1]`, or
>> > - `($deque->shift('value') ?: $deque)`, or
>> > - `my_userland_helper_shift_and_return($deque, 'value')`
>>
>> ... Those are all grotesque.
>
> True, I wasn't familiar with that event and whether your goal was to=20
> write as few lines as possible or as quickly as possible vs in a=20
> readable way to people familiar with php.
> That clears that up.

My goal with the AoC series was to 1. Demonstrate how functional-friendl=
y PHP today is and 2. Identify places where it is still not fully FP-fri=
endly so we can fix those.

Full writeup of my results here: https://peakd.com/hive-168588/@crell/ao=
c2021-review

(Assistance with any of those points raised is very welcome and requeste=
d.)

>> > My personal preference is against making this fluent.
>> > I'd rather expose an efficient datastructure that's consistent with=
 the
>> > rest of PHP's functionality to the extent possible,
>> > which userland can use to write their own fluent/non-fluent classes.
>> > There's drawbacks to returning `$this`, including:
>> >
>> > 1. Inconsistency with existing APIs making remembering what does wh=
at
>> > harder. Barely anything in php that I remember returns $this.
>> >
>> >=C2=A0=C2=A0=C2=A0 https://www.php.net/manual/en/arrayobject.append.=
php returns void.
>> >
>> >=C2=A0=C2=A0=C2=A0 https://www.php.net/manual/en/function.array-push=
 returns an int.
>>
>> So it's already inconsistent, and frankly neither of those returns is=
 useful.=C2=A0 If the existing convention is "inconsistently unhelpful",=
 then let's go ahead and make it helpful since "it's lame but at least i=
t's consistent" is not an argument here.=C2=A0 (Sometimes that is a vali=
d argument, but not in this case.)
>
> I won't know if anyone is strongly against fluent interfaces belonging=20
> in core, or strongly against adopting fluent interfaces in an ad-hoc=20
> way that would make it unclear if the vote was for/against the overall=20
> functionality or the new design choice.
>
> I'd rather not do this without a policy RFC such as the one that passe=
d=20
> for namespaces https://wiki.php.net/rfc/namespaces_in_bundled_extensio=
ns

I wouldn't call anything that returns $this "fluent".  "Fluent" is speci=
fically trying to make an API read like English, and most of the APIs I =
see that really lean into that heavily are multi-object and end up being=
 godawful.  This is simply "there's nothing else to return, so may as we=
ll return $this", which is extremely common.  (Auto-generated Doctrine e=
ntities do that almost universally for setters.)  In this case, doing so=
 also has a specific additional benefit beyond "might be nice".

As far as data collection, welcome to life in RFCs.  Forming consensus o=
n something before the vote happens is basically impossible, so you have=
 to design the best API based on limited feedback and then hope.  It suc=
ks, but that's neither here nor there.

At the moment I am leaning toward voting No if the return value remains =
void, because that cuts the usefulness of the object in half.  (Though t=
he performance note gives me pause; that's the only thing that does.)

> If you expect this to be widely considered a better design php should=20
> adopt, please create an RFC after the vote finishes (if it passes)=20
> before the feature freeze outlining which methods of `Collection\Deque=
`=20
> would change and how.

Such an RFC would almost certainly fail without support from the origina=
l author (you).

>> >=C2=A0=C2=A0=C2=A0 Developers might have several guesses/assumptions=
 based on their
>> > experience with other methods in php/elsewhere
>> >
>> >=C2=A0=C2=A0=C2=A0 - It returns the new count (JavaScript Array.push=
, array_push)
>> >=C2=A0=C2=A0=C2=A0 - It returns $this (Ruby)
>> >=C2=A0=C2=A0=C2=A0 - It returns a lazy copy, like you'd wanted, not =
modifying the
>> > original
>> >=C2=A0=C2=A0=C2=A0 - It's returning void and the code in question is=
 shorthand for
>> > `return null`.
>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Python, C++
>> > https://www.cplusplus.com/reference/vector/vector/push_back/ ,
>> > offsetSet and spl push()/shift() methods)
>>
>> Once again, the lack of a consistent pattern means we don't need to f=
ollow the pattern.=C2=A0 As with the first point, "it's silly but at lea=
st it's consistent" is a valid argument in many cases, and we've changed=
 the language accordingly before.=C2=A0 (Ternary associativity order com=
es to mind.)=C2=A0 That's not the case here.=C2=A0 There is no broad-bas=
ed ingrained training that people have that would lead them to expect a =
given return, so we can and should go for whichever one is most powerful=
/flexible/conducive to good code.=C2=A0 IMO, that's returning $this.=C2=A0
>
> I continue to disagree for my previously stated reasons.
>
>> (Again, since a purely functional version is apparently off the table=
.)
>
> I'd be in favor of immutable datastructures in core, but I don't think=20
> I'd have much success in an RFC.
> I've only heard from a few voters that are passionately for them, I'm=20
> not sure if that translates to widespread interest.

"A language teaches you to not want what it doesn't provide." - Most fea=
tures don't have widespread grassroots demand for them until they happen=
, and then they're super common.  (Some do, but most don't.)

As above, we don't know if anything is going to have enough support to p=
ass until the vote starts.  This is a known design flaw in PHP's develop=
ment process, independent of any particular RFC.

> Though interestingly (and unrelated to this RFC=20
> https://wiki.php.net/rfc/deque ), they do seem possible to implement=20
> with better asymptotic performance than I'd have expected.
> Google searching mentioned Relaxed Radix Binary Trees, an immutable=20
> datastructure surprisingly claiming performance near arrays in most=20
> operations.
> https://hypirion.com/musings/thesis https://github.com/hyPiRion/c-rrb

Sounds like we should add them. :-)

--Larry Garfield