On Fri, Jan 1, 2021, at 5:51 PM, Olle Härstedt wrote:
> >> The web dev discourse is
> >> one-sided with regard to immutability,
> >
> > Yes, if you've heard any of the regular whining about PSR-7 being an
> > immutable object you'd think it's one-sided in favor of mutability. ;-)
> >
> > As you say, the point here is to add tools. Right now, doing immutability
> > in PHP in syntactically clumsy and ugly. We want to fix that, and that has
> > to include some means of "give me a new value based on this existing value
> > but with some difference." (aka, exactly what with-er methods do, although
> > I agree entirely that if you have the option of less generic names, use
> > them).
> >
> > So, can we get back to the original post, which is proposing specifics of
> > the tools to make that happen? :-) (Asymmetric visibility and clone-with,
> > specifically.)
> >
>
> OK!
>
> I like that you connect higher level design patterns with language
> design. This is the way to go, IMO. Personally, I'd prefer support for
> the Psalm notation `@psalm-readonly`, which is the same as your
> initonly. Clone-with makes sense too, as this construct is already
> supported in multiple languages. The exact notation doesn't matter
> that much - my personal choice is OCaml {record with x = 10} over JS
> spread operator, but OCaml is pretty "wordy" in notation in contrast
> to the C tradition that PHP is part of.
>
> Reintroducing "objects that pass by value" is a hard pass from me. The
> way forward is immutability and constrained mutability (ownership,
> escape analysis, etc). Psalm also supports array shapes - maybe this
> can be investigated as an alternative? Since PHP has no tuples.
>
> I'm not convinced the added complexity of asymmetric visibility is
> powerful enough to motivate its existence. Feel free to prove me
> wrong. :) My choice here would be namespace "internal" (also supported
> by Psalm already), but this requires implementation of namespace
> visibility, a PR that was abandoned.
>
> And also, happy new year!
Happy New Year!
I agree that "objects, but passing by value" would not be the right solution. I
used to think that would be a good part of the solution, but eventually
concluded that it would introduce more complexity, not less. Eventually,
everything people wanted to do with objects they'd want to do with "Records"
(for lack of a better term), and if they pass by value but are still mutable
then you have a weird situation where sometimes changes propagate and some
don't (depending on if you have a record or object). Making it easier to use
objects in a value-esque way will get us closer to the desired end state.
I think the tldr of my post is this: A single "immutable" flag (whatever it's
called) on a class or property would require having lots of holes poked in it
in order to make it useful in practice (mostly what "initonly" would do), but
those holes would introduce other holes we don't want (cloning an object from
the outside when you shouldn't).
Asymmetric visibility, however, doesn't give us true immutability but allows a
class author to more easily emulate it "close enough", while also supporting
various other use cases. Its gap is the class author, not the entire rest of
the programming industry. That makes it much safer, and gets us to objects
that are effectively immutable from the outside, which is what's important.
(If they're mutable from the inside, either there are use cases for that or
rely on the good behavior of just the class author, who is in the best position
to know if the object should be internally immutable or not.)
Pairing that with an easy clone-with-change syntax would allow class authors to
easily construct something that is immutable-in-practice fairly easily, even if
it's not Twue Immutability(tm).
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
