On 4/11/2016 6:59 AM, Larry Garfield wrote: > There's an important point here that should not be missed. If these > values are "write once then locked', which I can definitely see as > useful, we need to have another shot at modifying them from __clone(). > If not, they are effectively useless for implementing objects in the > style of DateTimeImmutable or the PSR-7 Request/Response objects. > Locking after __construct or __clone (as appropriate) is done is fine, > but if we can't clone-and-modify then I would pretty much never find > value in this feature (no pun intended). >
*__clone* support is indeed extremely important, very good point.
> I agree that final seems like a potentially confusing keyword, as every
> other use of final (AFAIK) means "subclass cannot change this", but
> that's not at all the meaning here.
>
See other messages of mine in this thread.
> Another question, which unfortunately runs straight into the previous
> Properties RFC: If a public property is write-once, with the intent
> being that it's set from the constructor and then cannot be overridden
> but is publicly exposed... shouldn't an interface be able to declare it
> as well? It makes public properties safe to use in some cases, but you
> can't rely on that safely without an interface.
>
> (Which leads to "can interfaces define properties", which leads right
> back to "well what can you do with them", which leads back to the
> Properties RFC. Which I still want to see happen at some point if at all
> possible, as it would also subsume this question quite nicely.)
>
I do not see the relation to the RFC (not judging the actual RFC because
I liked the idea but never got into the topic to be able to judge) but I
understand the concern.
In my opinion interfaces in PHP are at the state of Java 7 interfaces
(or even a direct copy) and their functionality must be extended at some
point. Same happened in Java 8.
That being said, I agree that properties should be allowed in
interfaces, however, they must be automatically made *final* and
immutable (where I proposed the *val* keyword).
interface Example {
DateTimeImmutable $created;
function example();
}
Transforms to:
interface Example {
final public DateTimeImmutable val $created;
public function example();
}
Otherwise no consumer could rely on the interface to not change. Also
note that it does not require the RFC you mentioned because no setter,
unset, nor isset is necessary or possible if we handle it like this.
Support for mutable public properties is a different story but allowing
them would destroy the encapsulation and I am against it without anyone
bringing some good arguments that convince me.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
