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?
> 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.
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#.
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
>
