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
