On Mon, Jul 1, 2024, at 12:21 PM, Richard Miles wrote:
> Howdy Rob,
>
>>> I appreciate your feedback, and I think it’s valid. I try to compare my expectations
>>> to what is possible in typescript.
>>
>> I feel like Typescript is the wrong model to follow. The type system in Typescript is
>> Turing Complete (https://github.com/microsoft/TypeScript/issues/14833) and php barely has a type
>> system. It doesn’t even have consistent type checking, for that matter (properties are checked
>> differently than arguments which are checked differently than constructor arguments — and the fact
>> they agree with each other at all, is interesting, because they don’t arrive at the same
>> conclusions in the same way. I’ve been dealing with subtle bugs here for weeks on an unannounced
>> RFC implementation) and this is why generics is a can of worms: implementing it would essentially
>> force a rewrite of the type system into a proper type system.
>>
>> In my honest opinion, before we can even have this type of conversation, we need to have an
>> RFC about the syntax (there may already be one, I haven’t checked — and internet is spotty where
>> I currently am). The pattern matching RFC was proposed as though it would be written one way, people
>> have thrown out ideas of different syntax, but I don’t think there is an “official” syntax. A
>> good starting point may be to simply propose an RFC about syntax so future RFCs can be consistent.
>>
>> — Rob
>
> I actually did not know it was turning complete, very interesting!
> While it is easy for anyone to say, ‘we're not even close to
> typescript,’
> that’s precisely what brings me to the table. I would be happy with us
> just voting on syntax. It seems like past RFC’s only
> ever got hung up on generics (wrongfully?). I want to work on
> implementing generics, too, after this. I feel this is probably a good
> stepping stone.
>
> A vote would solidify the following:
>
>
> interface iArrayA ['a' => string ]
> interface iArrayB extends iArrayA ['b' => string, 'c' => ?string,
> ‘d’
> => SomeClass, ‘e’=> iArrayA, ‘f’ => mixed ]
> $array = (iArrayA &| iArrayB) [ ‘a’ => ‘hello’ ];
>
>
> That would allow us to move into an implementation discussion, which is
> also absolutely needed.
>
> Best,
> Richard Miles
As Stephen already said, we have this already. It's spelled like this:
class A {
public function __construct(public string $a) {}
}
class B extends A {
public function __construct(
public string $a,
public string $b,
public ?string $c,
public SomeClass $d,
public A $e,
mixed $f,
) {}
}
If you know the keys at code time, use a class, not an array. Full stop, period, end of story.
Using an array as a record object in PHP >= 7 *is wrong*. It's slower, more
memory-intensive, less ergonomic, harder to debug, harder to statically analyze, harder to learn,
harder to use. If you're still doing that, it's past time to stop. If your legacy
application from the PHP 3 days is still doing that, it's past time to upgrade it.
So new language features to make "misuse arrays as objects" easier are actively
counter-productive.
A Dict / Hashmap is appropriate when you do *not* know the keys in advance, and thus cannot use a
pre-defined object for it. There are plenty of use cases for that, but in that case, all you need
type-wise is the key type and value type, because all entries should be of the same type (give or
take inheritance). Mixing in random other types... is wrong. That's the whole reason why
people keep talking about collections/typed arrays/generics.
So the "array interface" syntax you keep posting is actively counter-productive.
--Larry Garfield