[Initial Feedback] Typed Arrays

If I were to choose between typed-array and collection like Derick showed a little bit I'd choose typed arrays definitely as a first feature to be merged into PHP.

Cheers indeed. I’m still looking for a karma sponsor ;)

Tuples are nice because they are bounded, they can probably act like arrays …

I’ve been leaning toward this working under the hood like SplObjectStorage and SplFixedArray.
For those who may not be super familiar, I’ve added the PHP documentation links:

https://www.php.net/manual/en/class.splobjectstorage.php
https://www.php.net/manual/en/class.splfixedarray.php

A typed array would/may not be a hash table, but a fixed list of some kind. I’ve had a few suggestions
and one individual in the is operator conversation said hash tables may be appropriate anyway.
Time will tell on this front and its implementation is worth the open discussion. What should be absolute
is that arrays with a ‘fixed’ type maynot assign members whoes types are not strictly defined. Thus, typed
arrays are stictly bound.

SplFixedArray acted like numeric Seq<> whereas SplObjectStorge adds functionionallity to our normal
arrays and acts our Dict<>.

I think a big issue this proposal solves is how to syntactically approach saying a member is present or null
or if member is present it should only be a string. The initial proposed syntax in the early feedback of the
pattern matching rfc poses:

So yes, [?'foo' => string] and ['foo' => ?string] are indeed
different.

A lot of discussion around this, but I think with interfaces this becomes trivail. Note my example code sovles
this using operators we already have: &, |, &|

interface iArrayA ['a' => string ]
interface iArrayB implements iArrayA ['b' => string, 'c' => ?string ]

// reads the same as a typecast
$array = (iArrayA &| iArrayB) [
‘a’ => ‘hello'
];

… (possibly even cast to them and vice-versa).

The way I implemented declaring types is actually just a typecast, so perhaps that should change or
we just extend the current array implementation to hold another metadata field.?

Best,
Richard Miles

pon., 1 lip 2024 o 03:01 Larry Garfield larry@garfieldtech.com napisał(a):

Hi Richard,

czw., 27 cze 2024, 22:33 użytkownik Richard Miles
richard@miles.systems napisał:

I worked with Joe Watkins to do a proof-of-concept for generic traits.
It's a bit old since it's from 2017, but could be a useful starting
point if you are serious about pursuing this idea:

https://github.com/php/php-src/compare/master...morrisonlevi:php-src:parameterized_traits

I’m also interested in this; it will help see branches like these.
Did you ever get the POC working? What did you feel like was the
biggest hurdle?

There even was an RFC in voting which Joe implemented and it addresses
nearly what is discussed it this thread https://wiki.php.net/rfc/arrayof

I must admit that the collection<Dict> proposal is bit too complex to
address such tiny but powerfully in my opinion functionality which is
typed array. What Derick showed looks more like generic collection and
such require declaring it's type. In my opinion this is way too mush
hassle to declare as many collection types as many usages in
application. Also two collection types with the same collection item
type will not be compatible from type perspective. While typed array
seems much more clear and compatible in all places where typed array is
needed without declaring separate type for each usage.

If I were to choose between typed-array and collection like Derick
showed a little bit I'd choose typed arrays definitely as a first
feature to be merged into PHP.

Cheers,
Michał Marcin Brzuchalski

Contextual point: Nearly every other major language at this point that has
a meaningful standard library has gone with a three-separate-object
approach (Seq, Set, Dict, called various things). At least Python,
Javascript, Rust, Kotlin, and Swift, in my research. (Go doesn't, but Go
avoids having features by design.) And AFAIK every language except PHP
and Lua separates sequences from dictionaries. Typed arrays will not full
resolve the seq vs dict problem, which is arguably PHP's original sin. And
there's a lot of weird issues to resolve around what the syntax could even
be, since PHP has untyped variables.

The custom collection syntax Derick has been working on is a second-best
alternative to generics, essentially. It is less ergonomic, no question,
but can also be implemented without generics, and so is about 5x easier to
do. If we could get native generics, then I think everyone involved agrees
building collections off of that -- in essentially the same way as every
language I mentioned above --- would be preferable to a custom one-off
syntax.

--Larry Garfield

Considering other languages it is worth mentioning that Java and C# have
generics AND typed arrays that act as a typed list/seq so sure it doesn't
solve all problems otherwise these languages wouldn't have both of them.

From my personal experience, a typed list/seq solves most cases where I
need the elements of an array to be strictly instances of a specific type.
What I see typed list/seq like string[] has more ergonomics, it can be
used to interact between libraries and application code without creating
intermediate objects, while collection<Dict> proposal always requires
declaring type - this simply multiplies the number of declared types and
create more coupling where it is not needed! Also, most cases I work with
are just fine with using just foreach or array_ family functions.

I believe typed list/seq could also be used to implement custom collection
like:

class Article {
function __construct(public string $title) {}
}

// collection(Seq) Articles<Article> {
// }

final class Articles {
public function __construct(protected Article[] $articles = []) {}
public function getIterator(): Traversable {
return new ArrayIterator($this->articles);
}
} // or extend any other collection class with just typed list/seq property

This doesn't have to collide with generics in any way, as mentioned before
in the thread these features may exist simultaneously, typed list/seq can
translate in the future to a generic type.
I believe it'd make people's lives easier if we could have this in place
soon.
Don't you agree?

Cheers,
Michał Marcin Brzuchalski

Hi Richard,

czw., 27 cze 2024, 22:33 użytkownik Richard Miles
richard@miles.systems napisał:

I worked with Joe Watkins to do a proof-of-concept for generic traits.
It's a bit old since it's from 2017, but could be a useful starting
point if you are serious about pursuing this idea:

https://github.com/php/php-src/compare/master...morrisonlevi:php-src:parameterized_traits

I’m also interested in this; it will help see branches like these.
Did you ever get the POC working? What did you feel like was the biggest hurdle?

There even was an RFC in voting which Joe implemented and it addresses
nearly what is discussed it this thread https://wiki.php.net/rfc/arrayof

I must admit that the collection<Dict> proposal is bit too complex to
address such tiny but powerfully in my opinion functionality which is
typed array. What Derick showed looks more like generic collection and
such require declaring it's type. In my opinion this is way too mush
hassle to declare as many collection types as many usages in
application. Also two collection types with the same collection item
type will not be compatible from type perspective. While typed array
seems much more clear and compatible in all places where typed array is
needed without declaring separate type for each usage.

If I were to choose between typed-array and collection like Derick
showed a little bit I'd choose typed arrays definitely as a first
feature to be merged into PHP.

Cheers,
Michał Marcin Brzuchalski

Contextual point: Nearly every other major language at this point that has a meaningful standard library has gone with a three-separate-object approach (Seq, Set, Dict, called various things). At least Python, Javascript, Rust, Kotlin, and Swift, in my research. (Go doesn't, but Go avoids having features by design.) And AFAIK every language except PHP and Lua separates sequences from dictionaries. Typed arrays will not full resolve the seq vs dict problem, which is arguably PHP's original sin. And there's a lot of weird issues to resolve around what the syntax could even be, since PHP has untyped variables.

The custom collection syntax Derick has been working on is a second-best alternative to generics, essentially. It is less ergonomic, no question, but can also be implemented without generics, and so is about 5x easier to do. If we could get native generics, then I think everyone involved agrees building collections off of that -- in essentially the same way as every language I mentioned above --- would be preferable to a custom one-off syntax.

--Larry Garfield

Just to add, the current implementation of arrays allows for using them as “sparse sequences” which is pretty unique to PHP. I’ve personally relied on this many times in my career (where we are only interested in non-zero elements) for scheduling, efficient matrices, and recommendation systems. It’s another type worth considering in the list you provided, assuming that Seq would strictly be a sequence.

— Rob