On Mon, Mar 16, 2020 at 12:23 AM Larry Garfield <la...@garfieldtech.com>
wrote:
> On Sun, Mar 15, 2020, at 4:44 PM, Máté Kocsis wrote:
> > >
> > > Avoiding that confusion will save the industry millions of dollars.
> > >
> >
> > On the one hand, you are right, because currently it's not very useful to
> > effectively provide two
> > ways of declaring a constant. On the other hand however, if we also
> > consider a longer term
> > aim of adding support for object default values (just like what Marco
> > mentioned):
> > public read-only DateTimeImmutable $startupTime = new
> DateTimeImmutable();
> > then allowing default values for "write-once" properties seems much more
> > sensible. At this point,
> > the "million dollar mistake" label doesn't hold anymore since class
> > constants and "write-once"
> > properties with default values will actually be two different things. But
> > we've just ended up at
> > Marco's suggestion:
>
> I'll be honest, I really have no idea how default object values is at all
> related here. I mean, those would be nice to have as well for various
> reasons, but I don't see how it's related to read-only properties.
>
Default object values are a case where default values for readonly
properties have a legitimate use-case, because the actual value will be
different for each object. Currently only constant values are permissible,
which will thus be the same for all objects, and as such not materially
different from class constants.
A few more considerations on how readonly defaults this would interact with
potential future language changes...
What happens if we introduce a shorthand syntax for combining property
declarations, constructors and initialization?
class Point {
public function __construct(
public readonly float $x = 0.0,
public readonly float $y = 0.0,
public readonly float $z = 0.0,
) {}
}
The naive transformation for this would be:
class Point {
public readonly float $x = 0.0;
public readonly float $y = 0.0;
public readonly float $z = 0.0;
public function __construct(float $x = 0.0, float $y = 0.0, float $z =
0.0) {
$this->x = $x;
$this->y = $y;
$this->z = $z;
}
}
Which of course will not work with readonly properties as defined.
Alternatively one could transform this without the default values on the
properties themselves, only on the arguments. That does lose out on
Reflection though.
The other one is the recently declined
https://wiki.php.net/rfc/object-initializer. As it basically works by first
creating the object normally (including a possible constructor call), and
then assigning the specified properties, this would not be compatible with
readonly properties that have defaults. Other implementation approaches are
possible though, but may not be easily reconcilable with the need to also
call the constructor.
Not really sure what I'm trying to tell you with this though :)
Nikita
> > > 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)
> >
> > Yes, this scenario definitely makes sense. I'm just not yet sold that it
> > will have any negative effects
> > if we don't restrict the usage of default values now. I understand that
> > it's usually advantageous to be
> > conservative with adding new features - especially when groping in the
> dark
> > - since we are the ones
> > who have to support and fix them later. That's why I was hesitant to add
> > property covariance to the
> > proposal.
>
> The negative effect is if we later decide that it's too much of a problem
> to have default values, because they're just too confusing (people debating
> if they should be a constant, people expecting them to be overwriteable,
> etc.), we can't simply remove them. That would be a large breaking change
> and not allowed, so we're stuck with 'em.
>
> Whereas if we don't add it now, we can see if people are really clammoring
> for it and in what situations. We let the PHP-using masses do the research
> for us to determine how read-only-default would actually be useful, or if
> it would be useful at all. Then we can add it later in a way that would
> actually be useful, or decide not to do it at all.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
