On Fri, Jun 21, 2024 at 6:58 PM Niels Dossche <dossche.ni...@gmail.com> wrote:
>
> On 21/06/2024 14:43, Robert Landers wrote:
> > On Fri, Jun 21, 2024 at 5:08 AM Andreas Hennings <andr...@dqxtech.net>
> > 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.
> >>
> >> For the variable binding, I noticed that we can overwrite the original
> >> variable:
> >> $x is SomethingWrapper { something: $x }
> >> In this case the bool return is not really needed.
> >> For now this usage looks a bit unintuitive to me, but I might change
> >> my mind and grow to like it, not sure.
> >>
> >>
> >> For "weak mode" ~int, and also some other concepts, I notice that this
> >> RFC is ahead of the type system.
> >>
> >> E.g. should something like array<int> be added to the type system in
> >> the future, or do we leave the type system behind, and rely on the new
> >> "guards"?
> >> public array $values is array<int>
> >> OR
> >> public array<int> $values
> >>
> >> The concern here would be if in the future we plan to extend the type
> >> system in a way that is inconsistent or incompatible with the pattern
> >> matching system.
> >>
> >> --- Andreas
> >
> > I'm always surprised why arrays can't keep track of their internal
> > types. Every time an item is added to the map, just chuck in the type
> > and a count, then if it is removed, decrement the counter, and if
> > zero, remove the type. Thus checking if an array is `array<int>`
> > should be a near O(1) operation. Memory usage might be an issue (a
> > couple bytes per type in the array), but not terrible.... but then
> > again, I've been digging into the type system quite a bit over the
> > last few months.
>
> And every time a modification happens, directly or indirectly, you'll
> have to modify the counts too. Given how much arrays / hash tables are
> used within the PHP codebase, this will eventually add up to a lot of
> overhead. A lot of internal functions that work with arrays will need
> to be audited and updated too. Lots of potential for introducing bugs.
> It's (unfortunately) not a matter of "just" adding some counts.
Well, of course, nothing in software is "just" anything.
As to how much overhead? I guess you could create a subtype of `array`
that is typed, then people could use it when they need it and if it
gets up-casted to an array, you can just toss out all the counts. As
far as down-casting to the typed array, it would be no less
inefficient than doing $arr = (fn(MyType ...$arr) =>
$arr)(...$someArray); right now.
Robert Landers
Software Engineer
Utrecht NL
