Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109260
MIME-Version: 1.0
References: <1b781e1e-3f27-485b-ab47-5eeaf9496548@www.fastmail.com>
 <CAAKU0u=B5LwjVaSk9u_MAuHb+qzaxSqnWdtZqtFS4fsD6dejpQ@mail.gmail.com>
 <0af67f9d-ce2a-476f-abad-385080ce14e8@www.fastmail.com> <CABdc3WqSo4RY2vNsTcGMZ9cVATH5FfK0sv0ePEOdRj1ENs4j7g@mail.gmail.com>
In-Reply-To: <CABdc3WqSo4RY2vNsTcGMZ9cVATH5FfK0sv0ePEOdRj1ENs4j7g@mail.gmail.com>
Date: Tue, 24 Mar 2020 10:21:01 +0100
Message-ID: <CAH5C8xVgDBcGTFjiqdTLsM3BjjAvTaONg+p_uCAi98_DS9+wrA@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dce86b05a1964578"
Subject: Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000dce86b05a1964578
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

In my opinion, one of the core assets of PHP is that it contains relatively
few syntactic sugar compared
to some other languages, e.g. C#. Maybe it's just me, but I believe it
makes the code written in PHP
easier to read. And I think this is what we should optimize for. Not for
saving a few lines of code,
but for making the code easier to read and understand.

Now, if we had constructor promotion, we should search for properties both
on the top of the class
and in the constructor. And I agree with Micha=C5=82, this kind of code can=
 get
out of hand of control very fast.
That said, I don't think that declaring properties in the constructor is a
good idea. It's also because
many people (including myself) tend to write static methods first (I mainly
use them as named constructors),
so we'd either lose track of properties declared in the constructor or have
to force a code style that
puts the constructor to the top. Also, some IDEs (but PHPStorm for sure)
can generate the constructor
very easily from the declared properties.

Speaking about the evaluation of "Write-Once Properties" and "Compound
Property Visibility",
I disagree in some regards. I'll start with the less important one:

> Because the write-once state is preserved across cloning, it makes
> Evolution worse.


I think it's quite expected that properties won't be writable after
cloning. That would be a very bad
design otherwise. That's why I think your real problem is the opposite:
that currently the clone operator
is not prepared for this change. That's why I missed the "Rust-like
cloning" (or the other clone variant
that I presented in the "write-once property" thread) as the solution of
the "Evolution" problem of
"write-once" properties.

My other problem with the evaluation of the "Immutability problem" is that
it suggests that immutability
is only an external concern, and it isn't a thing in the private/protected
scope. Why do you think so?
Currently (unfortunately) visibility is the only thing that can at some
extent (in external scopes) control
mutability in PHP. However, if we look at the problem from the type system
perspective, visibility has nothing
to do with it: we won't have any guarantee that a property is immutable
even if we make it private.

To be honest, my impression is that most of the problems you list (e.g.
verbose constructor, bean problem,
or even property accessors) mainly boil down to the verbosity of PHP (or
the "visual debt" problem
how some people calls it). As I wrote in the first paragraph, I don't think
it's a bad thing.

For example, if we had "compound property visibility" then we could
separate read/write visibility of properties
without using getters/setters (I think this is what you also wrote). If we
had property accessors then
besides the separation of visibility, we could have materalized properties
or properties that validate themselves.
Probably the syntax would become more concise, but effectively we would
make methods from the properties.
But I don't understand why is would be a good thing to have two types of
methods? How should we decide if we
should use normal methods or property accessors? I think the current
situation is much better: use getters
and/or setters to separate visibility of properties, and perform validation
in setters if you need it. And I
I still don't think that property accessors would solve the main use-case
of "write-once" properties.

Cheers,
M=C3=A1t=C3=A9

--000000000000dce86b05a1964578--