2021-01-03 16:55 GMT, Larry Garfield <la...@garfieldtech.com>:
> On Sun, Jan 3, 2021, at 8:28 AM, Olle Härstedt wrote:
>
>> >> 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).
>>
>> I new language feature needs to be both simple and powerful - it's not
>> enough to be only powerful. A second problem I see is how asymmetric
>> visibility would affect the readability of a class, putting extra
>> strain in understanding it. Thirdly, how does PHP differ from FP
>> languages like OCaml and Haskell in this regard, neither who uses
>> visibility in this way? What's acceptable in those languages that
>> would be unacceptable in PHP?
>>
>> Olle
>
> I'll disagree slightly. A language feature should introduce more power than
> it does complexity. Not everything *can* be made absolutely simple, but the
> power it offers is worth it. I'd say it should minimize introduced
> complexity, relative to the power offered. Complexity ideally is super low,
> but it's never zero simply by virtue of being "one more thing" that
> developers need to know how to read.
>
> So in this case, we need to compare the power/complexity of asymmetric
> visibility vs the power/complexity of "immutable... except in these
> situations." I would argue that asymmetric visibility is more
> self-documenting, because it states explicitly what those situations are.
>
> The other point is that, as noted, "initonly" creates a gap if you have
> properties that are inter-dependent. Those then cannot be made public-read,
> because that would also mean public-clone-with, and thus allow callers to
> violate property relationships. Asymmetric visibility does not have that
> problem.
Can you perhaps be a bit more clear on why initonly/readonly would be
a deal breaker? Seems to me like readonly would cover 80% of
use-cases? Which is to make data-value objects humane (and fast, since
you don't need getters anymore) to work with. Seems like you're
focusing too much on an edge case here. Maybe we should list the
possibly use-cases? Or at least the main target use-case.
If an object has invariants that need to hold, just throw an exception
in __clone to force use with withX() instead? Or, as you suggested,
improve __clone by giving it arguments?
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
