@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 <math...@rochette.cc>:
>
>
> 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.sil...@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
>>>
>>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Silvio Marijić
Software Engineer
2e Systems
