[RFC][DISCUSSION] Collection Inspection

Ok, here's another idea I've been mulling over. This I know is possible
because I've done it using user land code, specifically Drupal 8's
Assertion\Inspector class.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%
21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x

These methods provide a means to inspect collections - arrays usually but
also Traversables. They fill a hole in the PHP library - the ability to
check collection integrity.

IMO, it makes a lot more sense to check integrity when creating the
"array" structure. Instead, I would suggest to add a native Collection
type, that takes a "type" as argument. They aren't quite full generics,
but it does 1. fix something; 2. isn't really complicated.

What I am suggesting is to add a new syntax "Collection<$type>",
mimicking a class, but having a type as "argument":

Just like to point out if it's considered a class, or takes the same space
there is likely collisions. While most collection classes on github look to
be in a namespace, there are lots that aren't. Of course github only gives
us a view of open source projects that happen to be on github.

$a = new Collection<integer>;

And then $a can act as if you'd use an ArrayAccess'ed class.
Upon each set or update, the type of the value can then be checked
against the type.

Consequently, this would also mean you can type hint on Collection<type>
instead of for example an earlier suggested array of type, where upon
passing in the array each member was checked for its type (slow).

And on top of this, this could be extended to do proper generics too.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

Ok, here's another idea I've been mulling over. This I know is possible
because I've done it using user land code, specifically Drupal 8's
Assertion\Inspector class.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Comp
onent%21Assertion%21Inspector.php/class/Inspector/8.5.x

These methods provide a means to inspect collections - arrays usually but
also Traversables. They fill a hole in the PHP library - the ability to
check collection integrity.

IMO, it makes a lot more sense to check integrity when creating the
"array" structure. Instead, I would suggest to add a native Collection
type, that takes a "type" as argument. They aren't quite full generics,
but it does 1. fix something; 2. isn't really complicated.

What I am suggesting is to add a new syntax "Collection<$type>",
mimicking a class, but having a type as "argument":

$a = new Collection<integer>;

And then $a can act as if you'd use an ArrayAccess'ed class.
Upon each set or update, the type of the value can then be checked
against the type.

Agreed, and we can get almost there today with:

$collection = collection_of('is_int', [ 1, 2 ]);
$collection[] = M_PI; // exception thrown

given:

function collection_of(callable $validator, $input = []) {
$collection = new class($input) extends \ArrayObject {
public function offsetSet($index, $value) {
if (($this->validator)($value)) return
parent::offsetSet($index, $value);
throw new \DomainException;
}
};
$collection->validator = $validator;
foreach ($input as $key => $value) $collection[$key] = $value;
return $collection;
}

Consequently, this would also mean you can type hint on Collection<type>
instead of for example an earlier suggested array of type, where upon
passing in the array each member was checked for its type (slow).

Regrettably, class_alias cannot quite work here, because the validator is
passed at run-time, so making this part of the language seems a good place
to go.

Cheers,
bishop

IMO, it makes a lot more sense to check integrity when creating the
"array" structure. Instead, I would suggest to add a native Collection
type, that takes a "type" as argument. They aren't quite full generics,
but it does 1. fix something; 2. isn't really complicated.

What I am suggesting is to add a new syntax "Collection<$type>",
mimicking a class, but having a type as "argument":

$a = new Collection<integer>;

So would I be right in thinking this would mean adding basic support for
generics to the engine, but not letting new ones be defined in userland?
So, a bit like how internal or extension classes have the ability to do
more overloading of casts and operators than userland classes?

If so, I like the concept, but wonder whether the parts of the
implementation it would need are the easy parts of the hard ones. I
guess not being able to inherit from the generic would get rid of a
bunch of complexity, but don't really know where else the challenge lies.

Regards,

--
Rowan Collins
[IMSoP]

IMPLEMENTATION STYLE #1: collectionof operator
The style of implementation I like the most is a collectionof operator in
parallel to the instance_of operator. It would be instanceof's plural
brother, so

$arg collectionof \SomeClass

To pass the check $arg must be of the iterable psuedotype with all its
values being a \SomeClass object.

This is all well and good, but collection integrity checks are usually
going to be looking to see if all the members are the same scalar.

$arg collectionof string

For language consistency we would need to allow instance_of to do the
same,
which it currently does not.

$arg instanceof string

This does create duplication with the is_* family of functions, but
instanceof already overlaps is_a heavily.

I see no value to this operator being applied to non-array
traversables. Our iterators cannot always be reliably rewound, such as
when using generators. Checking that the generator returns only
strings would consume all the input and would therefore be useless.

I concur. I'd actually ask what the intended goal is here.

Is this to ensure that everything coming OUT of a collection is a given type,
or that everything put IN a collection is a given type?

Asserting that "at this point in time, everything in this collection is a
given type" is honestly fairly useless unless it's enforced to stay that way.
I can assert that "this array currently contains only strings", but the very
next line could change that. Unless we go the generics-lite route and allow
code to declare $x = array<string> (or whatever), in which case it becomes
"enforce on the way in", and now we never need to check it because we know
that only strings can be put in the array.

Plus, as Levi says, asserting that all values in a non-array iterable are a
given type requires a full scan, which is often a destructive operation.

The better solution IMO is to allow for objects that enforce type on write,
and for different objects that enforce type on read, even if lazy. That is
(pseudo code, do not take literally):

$a = new Collection<string>;
$a[] = 5; // This will TypeError

Which we can almost get now, but it causes an interface mismatch error:

class Strings extends ArrayObject {
public function offsetSet(string $k, $v) {
parent::offsetSet($k, $v);
}
}

But that's essentially the logic we'd want.

On the read side (which you'd want for a generator or similar), the logic
you'd want is essentially:

class Ints extends ArrayObject {
public function current() : int {
return parent::current();
}
}

Which lints fine, but when I tested it just now returns strings quite happily
without a type error, which seems wrong to me. (Why is it doing that, and is
it a bug?)

In any case, in neither situation is collectionof particularly useful. What
is useful is a syntax-level "this collection will only allow type X to be
added" specification and a "this iterable will always return type X"
specification, both of which would generate a runtime TypeError or a compile-
time error if it could be detected.

--Larry Garfield