Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111851
MIME-Version: 1.0
References: <CAJpLVh1Ys4Sn9=1vjXoTwT5U_PObiRiCu0meUwVocZKSUAfdVA@mail.gmail.com>
In-Reply-To: <CAJpLVh1Ys4Sn9=1vjXoTwT5U_PObiRiCu0meUwVocZKSUAfdVA@mail.gmail.com>
Date: Sun, 13 Sep 2020 19:58:12 +0200
Message-ID: <CAEPJdum_aJYB4PJ5xGqUEm6G4VSujS2Oma6onDXvwxNn2SqfLA@mail.gmail.com>
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f4d73405af35a90b"
Subject: Re: [PHP-DEV] Add interface implementation to class in separate file
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000f4d73405af35a90b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 12, 2020 at 10:23 PM Olle H=C3=A4rstedt <olleharstedt@gmail.com=
>
wrote:

> Hi internals!
>
> Separation of data and behaviour is both a fun and hard discussion,
> especially considering:
>
> * "It should be possible to add new features without touching old code";
> and
> * "Principle of Least Privilege" (never expose more than you have to)
> (https://en.wikipedia.org/wiki/Principle_of_least_privilege).
>
> There should (could) be a way to add new behaviour to old data without
> touching the old data (class). Traits won't work in this use-case,
> since they assume the same internal structure for all trait-using
> classes. Imagine the `stringable` interface and a `toString` trait. A
> __toString() method needs knowledge about the internal structure of a
> class Foo. Yet if we want to keep adding behaviour to Foo, we'll end
> up with either exposing too much of Foo, or expanding the class file
> indefinitely. Please note that composition is not a proper solution,
> since it requires exposure of Foo; composition leads to lack of proper
> encapsulation, or representation exposure.
>
> In Haskell it's possible to split instance implementation of
> type-classes into separate files. In Rust you can have a struct with
> private fields and put impl of behaviour in different files (but same
> crate).
>
> A similar feature in PHP could look like (using new keyword `expand`
> but could be anything, or even `extend` in new context):
>
> ```
> // File FooStringable.php
> expand Foo implements stringable {
>   public function __toString() {
>     // Full access to Foo's all private fields here.
>     // Assumes you can autoload Foo.
>     // Assumes usage of $foo->__toString(); will be configured with
> autoload to dynamically find the correct behaviour of Foo.
>   }
> }
> ```
>
> If you'd use composition instead, you'd maybe have a formatter class
> with a method `$formatter->toString(stringable $foo)`. This has the
> problem I mentioned with exposing too much of $foo; it breaks
> encapsulation. It has the benefit of being able to provide multiple
> toString methods with different formats, but would have to assume
> similar structure of the objects passed to it (defined with an
> interface), which is not always possible or desirable.
>
> The other way is inheritance, which doesn't scale over multiple
> behaviours. `FooWithStringable extends Foo`? No.
>
> Was I clear here? Do you understand the issues that this design
> pattern is trying to solve? Its purpose is to solve "keep adding new
> feature to old data" in a clean and proper way, while keeping
> information encapsulation.
>

Do I understand you correctly, it would be somewhat like "opening" up a
class and making changes to it in another file?

Certainly a powerful concept, but I would be very interested in the details
how that would interact with autoloading. If I have a class Foo loaded, and
its "extension" FooString with toString method not, then it would lead to
the "toString" code missing.

>
> Enjoy the weekend!
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000f4d73405af35a90b--