Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103248
MIME-Version: 1.0
References: <OFC3B3B597.83B37DA6-ON43258312.003C9894-43258312.003E5976@alfabank.ru>
In-Reply-To: <OFC3B3B597.83B37DA6-ON43258312.003C9894-43258312.003E5976@alfabank.ru>
Date: Mon, 24 Sep 2018 09:28:39 -0500
Message-ID: <CAESVnVqip8DNE_qZMXMfY3KwHpxMY+eoXuS05=qsvbm4D8GmKg@mail.gmail.com>
To: AGromov@alfabank.ru
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Pre proposal for "Class extension functions"
From: pollita@php.net (Sara Golemon)

On Mon, Sep 24, 2018 at 6:21 AM Andrey O Gromov <AGromov@alfabank.ru> wrote:
>
> I want to do RFS proposal for new language concept - Class extension
> functions.
>
Bring a little Javascript into PHP? Hrmm, maybe. I can see some value,
though I'd offer a few thoughts:

1. Consider requiring that a class opt in to allowing these methods.
e.g.  `class DateTime implements MethodExtensions {}`.  I know that
this cuts out the power of this feature considerable, but it also
limits the unexpected damage from that power.

2. Consider the impact on scoping.  If a mixin can suddently access
private properties in a foreign class, that may violate assumptions
made by that class.  Maybe treat mixins as having public scope to
avoid this problem, that would also avoid much of my worries expressed
in #1.

3. Pure bikeshed, I would make the syntax use the :: delimiter rather
than ->.   e.g.   function DateTime::localTime() { ... }   But that's
my C++ hat speaking.

-Sara