Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103251
To: internals@lists.php.net
Reply-To: "Andrew Gromov" <andrewgrom@rambler.ru>
Date: Tue, 25 Sep 2018 00:23:59 +0300
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_1537824239286934"
Message-ID: <1537824239.902316.28693.59265@mail.rambler.ru>
MIME-Version: 1.0
Subject: Re: Pre proposal for "Class extension functions"
From: andrewgrom@rambler.ru ("Andrew Gromov")

--_----------=_1537824239286934
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"

I=E2=80=99m thinking a lot about potential problems. Some of them you voice=
d, but not
all. My message was a question of whether the topic was interesting and whe=
ther
it should be formatted as RFC.


> Bring a little Javascript into PHP?

In fact, I looked at Kotlin :)

(https://kotlinlang.org/docs/reference/extensions.html)


> Consider requiring that a class opt in to allowing these methods.

I don't think so.

The main point of proposal are to give developers possibility to encapsulate
util-functions into classes for calling them more clean.

Also I see some others benefits and interesting future capabilities. But I'=
m not
yet ready to talk about it - need to think more.


> If a mixin can suddently access private properties in a foreign class

Yes, it is one of potential problems. Currently I can=E2=80=99t see simply =
way to avoid
private access.

But=E2=80=A6 On the other hand, we have a Reflection.

Need to weigh all pros and contras.


> I would make the syntax use the :: delimiter rather than ->

> e.g. function DateTime::localTime() { ... } But that's

'->' - object function, '::' - static function.

No need to select only one of them ;)


> The patch doesn't seem to handle inheritance conflicts, though.

This is a very primitive prototype patch for demonstrating how it can work


> For reference: monkey patching methods onto built-in classes is what gives

> you shenanigans like the discussion about `[].smoosh` in Javascript.

One will say "Garbage", and the second "Treasure=C2=BB.


When I can do something like this in PHP:


function string.explode($a):array {

return explode($a, $this);

}

$a =3D "Hello world".explode(' ');


I'll get drunk with joy :)


> This just opens up a ridiculously wide scope for =E2=80=9Cwe can=E2=80=99=
t add

> method X because of a BC break in userland code=E2=80=9D.

Yes. This is a main argument against.

But I have something to counterpose. Extension functions used in many langu=
ages.
Kotlin, for example, announce them as killer feature (and it is). And there=
 is
very little languages with more quivering attitude to a backward compatibil=
ity.

New functions to internal classes introduce very rare and all that you need=
 - is
more accurate migration. Anyway if you try to declare already declared func=
tion,
then you receive compile time error.

--_----------=_1537824239286934--