Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rochette.cc designates 62.210.206.189 as permitted sender)
To: internals@lists.php.net
References: <CAA69SC4th-Hkxj162xn3RWAG44tFkhGTo3Pm=mephPdSHfcHsw@mail.gmail.com>
 <CADqTB_jPm6BB78wCbvNVj0gzGUy=M6tdPhB0dH34U+AXZQgiDA@mail.gmail.com>
Message-ID: <30416a57-2cb5-d192-9b3d-1546a11d9661@rochette.cc>
Date: Mon, 21 Nov 2016 09:46:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101
 Thunderbird/51.0a2
MIME-Version: 1.0
In-Reply-To: <CADqTB_jPm6BB78wCbvNVj0gzGUy=M6tdPhB0dH34U+AXZQgiDA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] Immutability RFC
From: mathieu@rochette.cc (Mathieu Rochette)



On 20/11/2016 20:25, Rasmus Schultz wrote:
> Reading through the RFC and the replies, I'm confused about this question.
>
> Why would the comparison operators work any differently on immutable
> objects?
>
> If these were value objects, the question would make sense, but it doesn't
> sound like that's what you're proposing?
>
> With regards to the feature itself, I frankly don't feel like it makes any
> sense. I disagree with the entire premise of the RFC.
>
>> Currently PHP lacks native support for immutability.
> No, it doesn't. You show several examples of immutable classes in the RFC,
> then demonstrate a slightly more abbreviated syntax to accomplish the same
> thing.
>
>> Because of that user-land applications are using third party libraries or
> resort to custom implementations and still there is no easy enforcement of
> immutability.
>
> Really? There are third-party libraries for immutable classes? .... Why?
>
> It's true that there is no way for a class, internally, to enforce
> immutability on itself - but why would you need to do that? You're writing
> the class. If you want immutable state inside your class, simply don't
> change the state.
>
> Why would you need the language to enforce rules that you can already
> enforce with the language?
The two main reasons I can think of are: I want the language to help me 
(ie: sometime we make mistakes) & I want classes implementing that 
interface to be immutable (eg: PSR7)
>
>> Introducing this feature would help bring one unified solution to this
> problem, and also it would remove unnecessary logic from user-land
> applications.
>
> What is this unnecessary logic you're referring to? Get-methods generally
> do not contain logic. There is no more or less logic in the examples you
> show in your before/after code samples.
>
> Perhaps you mean boilerplate? So yes, this feature removes a little bit of
> boilerplate. Writing immutable classes becomes a little less ceremonious.
>
> I think that the problem of writing get-methods is exaggerated and somewhat
> contrived.
>
> This feature doesn't enable you to do something you couldn't do before - it
> obviates the need to write get-methods, but that's basically all, and I'm
> not even convinced that's a good thing.
>
> Public properties, in practice, are almost never used in PHP code. You very
> rarely see anybody use them, because they're not generally safe, e.g.
> permits client code to inject values of the wrong type, etc.
>
> What you're proposing will make public properties the default for immutable
> objects.
>
> This will lead to inconsistencies - for example:
>
> immutable class Name {
>      public $first;
>      public $last;
>      public function getFullName() {
>          return "{$this->first} {$this->last}";
>      }
> }
>
> This will get confusing quickly - you will have to learn or memorize which
> attributes of your model are available as properties or methods, e.g.
> $name->first is pretty far removed from $name->getFullName() both in terms
> of syntax and style.
>
> I think this will become quite confusing in practice, as nobody currently
> expects or looks for public properties.
>
> Also, having to refactor from a get-method to a public property, or
> vice-versa, becomes a chore that causes a breaking change.
you don't have to move from getters to public properties. It's not 
needed as a "security" point a view, but I think most will still use 
getter to access the object values. It's especially true if you are 
implementing interfaces (or immutable interfaces). from the rfc : 
"Notice in above examples removing getters and setting properties to 
public is optional. They simply doesn't need to be protected anymore in 
fact that immutable class objects are deeply frozen with eceptions on 
write."
>
> The term 'immutable", especially for the property-annotation, doesn't
> strictly seem correct to me either, as for example, I can annotate a public
> property as immutable, but if I put an object in there, that object is not
> necessarily immutable. The correct term for this feature, especially for
> properties, I would think is "readonly" - which would be consistent with
> the description of certain existing properties in PHP APIs, such as
> PDOStatement::$queryString, as well as with other languages such as C#.
I'm not sure about that one because I can't find it explicitly in the 
rfc (maybe it need to be added ?) but I think immutable properties only 
accept immutable scalar or objects. otherwise you're right, it would not 
be immutable
>
> Either way, this feature proposes to introduce "asynchronous" properties as
> a new concept in PHP, where properties are generally "synchronous", in the
> sense that they can always be read and written. Other languages that
> support asynchronous properties (C#, Objective-C, Dart, probably many
> others) typically leverage that concept for more than just simple
> immutability - the concept of properties that behave differently when you
> attempt to read and write is not typically a mere annotation/directive
> instructing the compiler to enforce a rule, it's typically made possible
> via support for accessors.
>
> This might limit future options for the language, perhaps depending on how
> it's implemented.
>
> I hope it doesn't mean we can't have accessors at some point, in the
> distant future.
>
> In my opinion, all of these things go hand-in-hand: accessors, read-only,
> property type-hints, as these are all essentially about defining and
> enforcing constraints and making assertions about the state of a model.
>
> I feel that this feature is a poor substitute for accessors, for example,
> because this feature really applies only to immutable models - whereas a
> feature such as accessors could be used equally to create immutable models,
> but would permit us to move away from get/set-methods entirely, e.g. would
> allow to write models with more consistent APIs, for example something like:
>
> class Name {
>      public readonly $first;
>      public readonly $last;
>      public $full_name {
>          get { return "{$this->first} {$this->last}"; }
>      }
> }
>
> Something like that makes for more consistent client code, e.g.
> $name->first and $name->full_name, etc.
>
> I'd like to see us adding features that work everywhere, for many
> use-cases, mutable and immutable - introducing a language feature that
> works only for immutable objects just feels to exotic to me, in a language
> that is mutable by default.
>
> I'd prefer to see features with broader applications.
>
>
> On Wed, Nov 16, 2016 at 2:57 PM, Silvio Marijić <marijic.silvio@gmail.com>
> wrote:
>
>> Hi,
>>
>> To anyone who is interested in this RFC. What do you think what behavour we
>> should have when you try to compare two immutable objects by identity like
>> this:
>>
>> immutable class A {
>>
>> public $a;
>>
>> public function __construct($a) {
>>     $this->a = $a
>>      }
>>
>> }
>>
>> $a1 = new A(1);
>> $a2 = new A(1);
>>
>> $a1 === $a2
>>
>> If we treat those objects as values then this should return true. But then
>> again there might be some confusion because then two operators are doing
>> the same thing. Maybe throw an error ? Suggestions ?
>>
>> Cheers.
>> --
>> Silvio Marijić
>> Software Engineer
>> 2e Systems
>>