@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 <da...@php.net>:
> On Sun, Dec 11, 2016 at 7:40 PM, Mathieu Rochette <math...@texthtml.net>
> wrote:
>
>>
>>
>> On 12/12/2016 01:16 AM, Silvio Marijić 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 <la...@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 = clone($this);
>> >>> $new->amount += $other->amount;
>> >>> return $new;
>> >>> }
>> >>> }
>> >>>
>> >>> I'm not sure how easily we can denote that sort of case. It's outside
>> >>> 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 build
>> >>> new altered object from an existing one could be improved. Different
>> >>> options were proposed but maybe it's better to start small to get this
>> >>> 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 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 == $instance, so access to private/protected
> return $instance->bar;
> }
>
> public function withBar($bar) with (Foo $instance): Foo
> {
> $instance->bar = $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
>
>
>
--
Silvio Marijić
Software Engineer
2e Systems
