2021-01-01 19:14 GMT, Larry Garfield <la...@garfieldtech.com>:
> On Thu, Dec 31, 2020, at 8:04 AM, Olle Härstedt wrote:
>> 2020-12-31 12:37 GMT, Rowan Tommins <rowan.coll...@gmail.com>:
>
>> > On 30/12/2020 18:42, Olle Härstedt wrote:
>> >>> To put it a different way, value types naturally form*expressions*,
>> >>> which mutable objects model clumsily. It would be very tedious if we
>> >>> had
>> >>> to avoid accidentally mutating the speed of light:
>> >>>
>> >>> $e = (clone $m) * ((clone $c) ** 2);
>> >> Using a variable on right-hand side does not automatically create an
>> >> alias, so in the above case you don't have to use clone.
>> >
>> >
>> > Whether or not the type system forced you to, you'd have to use clone
>> > if
>> > the values were implemented as mutable. Switching to methods again may
>> > make that clearer:
>> >
>> > $c = new MyNumber(299_792_458);
>> > $m = new MyNumber(10);
>> > $e = $m->multiply( $c->square() );
>> >
>> > If multiply() and square() are mutating state, rather than returning
>> > new
>> > instances, $c is now 89875517873681764, which is going to totally mess
>> > up the universe...
>> >
>> >
>> > Regards,
>> >
>> > --
>> > Rowan Tommins
>> > [IMSoP]
>>
>> Yes, of course you can find use-cases where immutability is a better
>> choice, just like I can find use-cases where (constrained) mutability
>> is better. The point is not to replace one tool with another, but
>> rather adding another tool to the toolbox. The web dev discourse is
>> one-sided with regard to immutability, I think. Wish I had time to
>> implement a PR to Psalm to show something more concrete... Again, if
>> you only have a hammer, everything looks like a nail. :)
>>
>> Olle
>
>> 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!
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
