Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97364
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANaX5ne-kvAMzLuc3+tpuXr3vGcdfC1xeSZg42=U1CWzXJMbcA@mail.gmail.com>
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> <CANaX5ne-kvAMzLuc3+tpuXr3vGcdfC1xeSZg42=U1CWzXJMbcA@mail.gmail.com>
Date: Mon, 12 Dec 2016 10:11:17 +0100
Message-ID: <CAA69SC4MLO7KLWuMcQZw2g86tvbjK6rtxSQsfdN0ApmKM8=4=w@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: Mathieu Rochette <mathieu@texthtml.net>, Larry Garfield <larry@garfieldtech.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f6c1c899b630543727c0c
Subject: Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a113f6c1c899b630543727c0c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Davey,

There was similar suggestion that $this represents clone of the object. I
think that is a bit vague, and I'am not sure about the 'scope' you refer to
because 'double scoping' could be also a reason to downvote this rfc and it
can lead to confusion in my opinion. I will check HHVM also.

Regarding my proposal above, since copy() would essentially operate only on
immutable objects, why not put it only there. So you would be able to make
a call like this one $immutable->copy(array $args); or $this->copy(array
$args); depending on whether you are inside let's say with* method or
outside of the object.

2016-12-12 6:58 GMT+01:00 Davey Shafik <davey@php.net>:

> 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 an=
y
>> >>> non-trivial object (more than 1-3 internal properties) creating a ne=
w
>> >>> 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 outsi=
de
>> >>> 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 bui=
ld
>> >>> new altered object from an existing one could be improved. Different
>> >>> options were proposed but maybe it's better to start small to get th=
is
>> >>> first part right and add this in another rfc ? having everything at
>> the
>> >>> 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 an=
d
>> >> 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 i=
s
> 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
>
>
>


--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a113f6c1c899b630543727c0c--