Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <30416a57-2cb5-d192-9b3d-1546a11d9661@rochette.cc>
References: <CAA69SC4th-Hkxj162xn3RWAG44tFkhGTo3Pm=mephPdSHfcHsw@mail.gmail.com>
 <CADqTB_jPm6BB78wCbvNVj0gzGUy=M6tdPhB0dH34U+AXZQgiDA@mail.gmail.com> <30416a57-2cb5-d192-9b3d-1546a11d9661@rochette.cc>
Date: Mon, 21 Nov 2016 10:10:09 +0100
Message-ID: <CAA69SC7UJYCp8ttWLywjMWUcc3O1G4ucP0QfNbBD87j0Od=QYA@mail.gmail.com>
To: Mathieu Rochette <mathieu@rochette.cc>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114073f8d458010541cc05d7
Subject: Re: [PHP-DEV] Immutability RFC
From: marijic.silvio@gmail.com (=?UTF-8?Q?Silvio_Mariji=C4=87?=)

--001a114073f8d458010541cc05d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Rasmus

We are not changing behaviour of operators since we are not dealing here
just with Value Objects.
It's not even a question that matter of this RFC can be achieved with
encapsulation. Already there are couple of features that got passed, which
also could be achieved without 'syntax' sugar, so I don't think that is a
valid argument, but I'm not going to into any of that, since it would not
result in any constructive argument.

I do have to apologize for still incomplete RFC. Your question regarding if
you declare property immutable and put 'non' immutable object  there has
been addressed from beginning.

And also regarding getters, I really see them as a neccesary evil, the more
internal state you expose, the more you have to test since that's you
contract to the rest of application and etc.

Cheers,
Silvio.

2016-11-21 9:46 GMT+01:00 Mathieu Rochette <mathieu@rochette.cc>:

>
>
> On 20/11/2016 20:25, Rasmus Schultz wrote:
>
>> Reading through the RFC and the replies, I'm confused about this questio=
n.
>>
>> 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 a=
ny
>> 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 RF=
C,
>> then demonstrate a slightly more abbreviated syntax to accomplish the sa=
me
>> thing.
>>
>> Because of that user-land applications are using third party libraries o=
r
>>>
>> 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 writi=
ng
>> 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 generall=
y
>> 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 whi=
ch
>> attributes of your model are available as properties or methods, e.g.
>> $name->first is pretty far removed from $name->getFullName() both in ter=
ms
>> of syntax and style.
>>
>> I think this will become quite confusing in practice, as nobody currentl=
y
>> 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 n=
ot
>> 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 accep=
t
> 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 t=
he
>> 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 yo=
u
>> 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 h=
ow
>> 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. wou=
ld
>> 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 langua=
ge
>> 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=C4=87 <marijic.silvio@gma=
il.com
>> >
>> wrote:
>>
>> Hi,
>>>
>>> To anyone who is interested in this RFC. What do you think what behavou=
r
>>> 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 =3D $a
>>>      }
>>>
>>> }
>>>
>>> $a1 =3D new A(1);
>>> $a2 =3D new A(1);
>>>
>>> $a1 =3D=3D=3D $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 doin=
g
>>> the same thing. Maybe throw an error ? Suggestions ?
>>>
>>> Cheers.
>>> --
>>> Silvio Mariji=C4=87
>>> Software Engineer
>>> 2e Systems
>>>
>>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
Silvio Mariji=C4=87
Software Engineer
2e Systems

--001a114073f8d458010541cc05d7--