Hey Larry,
> From: Larry Garfield <[email protected]>
> Sent: Thursday, June 21, 2018 18:17
> To: [email protected]
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> Questions along the way:
>
> * There was at one point in time a related RFC regarding property
accessors
> (dedicated getter/setter methods for each property that get called
> automatically). That was rejected largely on performance grounds at the
> time.
> Would this RFC 1) Hinder returning to property accessors in the future 2)
Help
> resolve some of the issues there indirectly 3) Have no effect on the
viability
> of accessors?
I don't think it'll hinder them, accessors are pretty orthogonal to this
feature. Sure they'll have to cast the returned value according to the
property type, but that's no different than a return type and just like
__get() works in this RFC. But that's already about the complete impact.
An accessor ultimately isn't really any more expensive than a __get() call
at a fundamental level.
> * How much compile time detection is possible? Eg, the following code
> would clearly never work:
>
> class Foo {
> protected int $val;
>
> public function setVal(string $val) : void {
> $this->val = $val;
> }
>
> public function getVal() : string {
> return $this->val;
> }
> }
>
> (I suppose technically it might work in coercive mode, but not strict
mode?)
> Would this be a compile time error, or a runtime error when you first try
to
> run it? (I'm assuming IDE linters would be able to catch it, but if the
engine
> could too that's even better.)
PHP core generally does no type analysis at all at compile-time. Any type
analysis is happening in opcache/Optimizer and until now opache/Optimizer
hasn't chosen to warn if it encounters impossible conditions. This may or
may not change in future, but isn't related here.
So it is a runtime error; any other behavior would be out of scope of this
RFC.
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
