Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109108
MIME-Version: 1.0
References: <CAH5C8xVY5SFLBt2jZ9dx93rQC_Xjp4pKZJ+MP=K1TbjyDi9CDA@mail.gmail.com>
 <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com>
In-Reply-To: <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com>
Date: Tue, 17 Mar 2020 17:48:34 +0000
Message-ID: <CA+kxMuRMqv4Mi3LGpgH+SicCZG8FaUF_3TXaMjGTw7j_rDsw9Q@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties
From: Danack@basereality.com (Dan Ackroyd)

Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote:
(from the other thread)
> there must be a way to work around the keyword -
> either via reflection or another means.

Can you expand on why there 'must' be a way to work around this? Can
you provide some example code where not being able to change the value
is going to cause problems.

> I voted against the RFC because it has too many rough edges to me.
> eg cloning doesn't work, the initialization needs special rules, etc.

To be clear, cloning would work....but just not be useful. But being
required to write a function to copy an object, and overriding the
values doesn't seem like a terrible burden. And, because PHP has an
evolved type system, it is always going to have some 'special rules'
for certain things, just because of maintaining BC.

> I don't think these issues can nor should be figured out later on: they are
> low-level conceptual issues IMHO.

I can't see where the edge-cases are going to bite us. What's an
example of where they can't be figured out later? btw I totally agree
that having them now would be nicer...

cheers
Dan
Ack