On Sun, 23 Jun 2024 at 18:28, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Thu, Jun 20, 2024, at 8:35 PM, Andreas Hennings wrote:
> >> Ilija and I have been working on and off on an RFC for pattern matching
> >> since the early work on Enumerations.
> >
> > I like what I see, a lot!
> > One quick thought that came to my mind, regarding objects:
> > Could we check method return values?
> >
> > if ($x is Countable { count(): 0 }) ...
> > if ($p is Point { getX(): 3 }) ...
> > if ($x is Stringable { __toString(): 'hello' }|'hello') ...
> > while ($it is Iterator { valid(): true, current(): $value, next(): null })
> > ...
> >
> > Maybe it goes too far.
>
> Much to my surprise, Ilija says that's technically possible. However, now
> that we have property hooks the need for calling a method is far less, so
> we'd rather not in the interest of simplicity for now. A future-RFC could
> probably add that if it's really needed, but I don't think most languages
> support that anyway. (Need to verify.)
>
> --Larry Garfield
Even if property hooks will be available at the time, a lot of classes
will be from other packages that use getter methods to communicate.
And, even with property hooks, there will be use cases where getter
methods remain the preferable implementation choice.
But ok for me to push things like this to follow-up RFCs.
This leads me to a different question regarding property guards.
What if we validate an object property guard, which later changes?
class C {
public function __construct(
public readonly Point $point is Point { $z: 0 };
) {}
}
$c = new C(new Point(0, 0, 0));
$c->point->z = 5;
The second operation would violate the guard condition.
However, I suspect that the operation will not trigger any validation
for a guard where the object is referenced.
So it would be up to the developer to only use this if Point::$z is
readonly, or they cannot rely on the guard.
