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
