Re: Discussion: String streams
| From: | Sara Golemon | Date: | Tue, 22 Mar 2022 18:02:47 +0000 |
| Subject: | Re: Discussion: String streams | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117401@lists.php.net to get a copy of this message | ||
On Tue, Mar 22, 2022 at 10:28 AM Pierre <pierre-php@processus.org> wrote:
> Le 22/03/2022 à 16:14, Sara Golemon a écrit :
> > Who's just a hard-nope on userspace operator overloading? If your
> reasons
> > go beyond foot-gun (and that is a valid reason), could you share what
> those
> > reasons are?
> >
>
> I am a not so hard-nope against userland operator overloading because
> it's magic. My day job is 20% writing code, 30% speaking with clients,
> and 50% reading and using community code. Userland operators are not as
> explicit as verbose method calls; and you can't ctrl-space an operator
> in any existing IDE, it's not obvious at what they does when you read
> code using them in most cases, and beyond that, in order to use them,
> you have to read an external documentation.
Yup. I generally file this all under the 'foot-gun' objection, because at
the end of day if you've made an overload interface that makes your code
hard to read and reason about, then you *have* foot-gunned yourself. Not
dismissing it at all, because the struggle IS real.
> And in the end, operators are just sugar for method calls. I don't
> dislike writing $c = $a->plus($b) instead of $c = $a + $b, I even found
> that there's some kind of elegance behind writing stuff explicitly.
> There's no feature in the world that would be blocked by the lack of
> operator overloading.
>
>
100% not going to argue with you on the accuracy of that statement. Of
course, something being sugar doesn't mean it's not sweet. ;)
-Sara