Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97363
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.161.171 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <79ea244b-9fe7-5b05-d429-bf5585215542@texthtml.net>
References: <CAA69SC7sfDOyd1oMTGF7gHLe+MXbtr4nqpQ0eufxKyWChrm9Jg@mail.gmail.com>
 <1807f949-81d3-f2c4-8706-0fdade3ea51d@garfieldtech.com> <4635ac4b-844a-b023-5ad9-e8524a156404@texthtml.net>
 <fa72c5af-822c-3716-f562-b069ba5ef9b8@garfieldtech.com> <CAA69SC477BGX-8tYGRrv-o1RYYzC3wzD-vWUWR9Gbpcz+QStxQ@mail.gmail.com>
 <79ea244b-9fe7-5b05-d429-bf5585215542@texthtml.net>
Date: Mon, 12 Dec 2016 00:58:52 -0500
Message-ID: <CANaX5ne-kvAMzLuc3+tpuXr3vGcdfC1xeSZg42=U1CWzXJMbcA@mail.gmail.com>
To: Mathieu Rochette <mathieu@texthtml.net>
Cc: =?UTF-8?Q?Silvio_Mariji=C4=87?= <marijic.silvio@gmail.com>, 
	Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1142216e672fc805436fccfa
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: davey@php.net (Davey Shafik)

--001a1142216e672fc805436fccfa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette <mathieu@texthtml.net>
wrote:

>
>
> On 12/12/2016 01:16 AM, Silvio Mariji=C4=87 wrote:
> > This have occurred to me also, I wanted to separate that into two RFC's=
,
> > but then how we deal with RFC's that depend on each other?
> well that's just my opinion but I don't think they depend on each other,
> this rfc seems useful on its own. The "clone" one might depends on this
> one but it does not *need* to either (otoh it certainly would be much
> more useful with immutable classes than mutable classes)
>
> plus, this part might already trigger enough discussion and adding
> everything at once might get confusion. I can think of : clone, late
> initialization, DateTimeImmutable and probably other subjects that could
> make the discussion noisy
>
> I'm not as familiar as you are with this mailing list so I might very
> well be wrong too ^^
> >
> > 2016-12-12 1:03 GMT+01:00 Larry Garfield <larry@garfieldtech.com>:
> >
> >> Assuming this was intended for the list...
> it was, thank you
> >>
> >> On 12/11/2016 05:55 PM, Mathieu Rochette wrote:
> >>
> >>> Currently the only "unlocked context" for an object is its
> >>> constructor.  As discussed previously, that is insufficient.  For any
> >>> non-trivial object (more than 1-3 internal properties) creating a new
> >>> one via the constructor only when incrementally building is
> >>> prohibitively difficult.  The pattern of with*() methods that spawn
> >>> new objects via clone(), a la PSR-7, needs to be supported.  That is:
> >>>
> >>> immutable class Money {
> >>>    // ...
> >>>
> >>>    public function add(Money $other) : Money {
> >>>      $new =3D clone($this);
> >>>      $new->amount +=3D $other->amount;
> >>>      return $new;
> >>>    }
> >>> }
> >>>
> >>> I'm not sure how easily we can denote that sort of case.  It's outsid=
e
> >>> the __clone() function itself, which is what makes it difficult.
> >>> Without that, though, such immutable objects are of only limited use.
> >>>
> >>
> >>
> >>> As you said, it has been already been discussed that a method to buil=
d
> >>> new altered object from an existing one could be improved. Different
> >>> options were proposed but maybe it's better to start small to get thi=
s
> >>> first part right and add this in another rfc ? having everything at t=
he
> >>> same time might makes the rfc more difficult to be accepted
> >>>
> >> On the contrary, an RFC that doesn't fully solve the issue at hand and
> >> leaves major gaps in place is a poor RFC, and I would expect to be
> >> justifiably voted down.
>

I wonder if we can essentially make all public methods act like they are
static (no access to $this) and then use something like:

immutable class Foo {
     protected $bar;
     public function getBar() with (Foo $instance): string // $instance is
a clone of $this
     {
           // context =3D=3D $instance, so access to private/protected
           return $instance->bar;
     }

    public function withBar($bar) with (Foo $instance): Foo
    {
         $instance->bar =3D $bar; // Allowed as we're in scope
         return $instance;
    }
}

Only operations in the scope of the class itself (and it's descendants,
adhering to standard visibility rules) can make changes on the cloned
variant. The `with ($instance)` is optional, $instance is just a variable
name. In reality you'll want to use it most of the time I imagine.

I suppose you can re-use the `use` keyword here too.

Also, this shouldn't allow for immutable properties.

Another option is to look at the way that HHVM does immutable types, though
that is _file_ based.

- Davey

--001a1142216e672fc805436fccfa--