Hey Máté,
On Sun, Mar 15, 2020, 14:04 Máté Kocsis <kocsismat...@gmail.com> wrote:
> Hi Marco,
>
> Yes, it still allows default values.
>
> The reason why I'm reluctant to disallow them is that this restriction
> would feel a bit ad-hoc for me. I mean, I wouldn't like to add another
> special rule for "write-once" properties, unless there is a strong
> argument for it. Besides, as far as I know there is no precedents of
> disallowing default values of similar properties in other languages,
> so I feel that the feature would stay the most intuitive as it is now.
>
I think what will happen is that people will start requesting for read-only
properties with default values to be over-writable-once (a mess): better to
remove them from the equation completely, no?
> However, I'm eager to listen any objections about this. I know for one
> that ProxyManager wouldn't work with "write-once" properties having
> default values. But can we consider this use-case an edge case, right?
>
Yeah, that's totally unrelated to library technicalities: since reflection
will tell us if a property is write-once, we can work around it regardless.
Could users circumvent the issue just by changing the default value
> to an assignment in the constructor? Or would it cause a big headache
> for them?
>
I would say that this complicates the semantics more, but you see that the
issue is indeed a bit more deep than what we wanted to tackle, so I think a
sensible solution is to:
1. Prevent the parser from accepting default values on write-once
properties (parser error)
2. Re-introduce them once we know what we want to do with default values
(and it makes sense)
We can then use the fact that nobody is relying on them to play with the
future scope.
Nikic suggested (in chat) an example usage such as default non-scalar
values as viable:
class Application
{
public read-only DateTimeImmutable $startupTime = new DateTimeImmutable
();
// ...
}
