[RFC:generics]

Hi, Here are a couple of comments towards Generics support to PHP. 1- Even though mentioned, I'd still use "extends" or "implements" instead of "is" (which would be a new pseudo-reserved keyword) to enforce data type consistency and prevent developers to potentially referring to one thing while consider another. 2- I'd avoid blindly inferring generic type using constructor without notifying the user about this being a generic class. I'd still prefer a diamond operator <> to be used. This would be specially valid if we ever decide to merge typed properties too. Example: class Foo { private Bar<string> bar; public function __construct() { $this->bar = new Bar<>("Hello World"); // Can be omitted because of typed properties already defined it } } 3- I didn't see any description related to nested generic type definition. I hope it is supported. Example: $pair = new Tuple<string, Map<string, Foo>>(); 4- Another thing not mentioned in the RFC is if constructor also support generic typing, like this: class Foo<A> { public function __construct<B>(B $b) {} } $foo = new Foo<string>(1); 5- Java provides an enforcement that you can specify multiple bounds. Imagine a class that contains a generic that that must extend class A, but also implement interfaces B and C. We'd enter in a language recognition problem if we take the same approach as class declaration as definition, such as: class Foo<T extends A implements B, C> In order to properly solve this, Java takes the approach of &, and require the class to be first and interfaces later, like this: class Foo<T extends A & B & C>. As I already mentioned in comment #1, we should stick to extends and implements, but adopt & as multiple interface implementation, like this: class Foo<T extends A implements B & C> {} 6- This could be an independent RFC, but ideally we should support generic typed arrays using the [] syntax, like this: function sortElements<E extends Element>(E[] $elements) : E[]; 7- Typed returns are also not mentioned in RFC: function newEntity<E implements Entity>($id) : E; $user = newEntity<User>(UUID::v4()); 8- RFC only handles upper bound generic types, but no support is mentioned about lower bound generic types. An upper bound generic type is when it restricts the unknown type to that type or one of its inherited types. In RFC this is specified by the "is" keyword and I suggested to still segregate it to "extends" as highlighted in comment #1. A lower bound generic type is when it restrict the unknown type to that type or any of the is parent types. I'd suggest to use "parent", "parents", "parentof" or "super". Example: class A {} class B extends A {} class C extends A {} class D extends B {} class Foo<T parent B> {} // T can be an instance of A or B but never C or D. 9- Although not clearly clarified in RFC, I saw some inference over unbounded wildcard types. However, nothing is mentioned about wildcard upper bound and wildcard lower bounds. A few examples: // Unbounded wildcard type function sort(List $list) : void; // ... how Java (here, PHPized) does it: function sort(List<?> list) : void; // Wildcard upper bound in Java (PHPized) function sortElements(List<? extends Element> $list) : void; // Wildcard lower bound in Java (PHPized) function addAll(List<? super Integer> $list) : void; There're problems of using the unbounded wildcard generic type, but I think you may have to dig through Java language specification to better understand what I'm saying. You can poke me privately and I can point out documentation that exposes its limitations/constraints. 10- Reflection plays a very important piece in this support and IMHO it must be documented with proposed API for verification. A link to a gist is not enough to fully understand what is proposed, so I'm abstaining from reviewing it until it gets properly mapped out in RFC. I hope I gave enough insight of what I consider that needs to be expanded in RFC, expanded in the proposal, highlighted better, etc. Still, this RFC is the best attempt I've seen towards improving the reusability of data structures in PHP. Nice work! =) Regards, On Tue, Apr 19, 2016 at 9:17 PM, Sara Golemon <pollita@php.net> wrote:

I agree. On Wed, Apr 20, 2016 at 2:01 PM, Sara Golemon <pollita@php.net> wrote:

On Wed, Apr 20, 2016 at 11:10 AM, Dominic Grostate < codekestrel@googlemail.com> wrote:

That would be a wise move, there are currently some RFCs with similar areas of contention

I don't know if mid-thread answering may lead to top-posting, but if it does, I'm sorry... =\ Answer inline: On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate < codekestrel@googlemail.com> wrote:

Unions and Intersections are required anyway, and I don't see how you can implement generics without supporting them. Let's say I'm implementing a cache library that segregate the interface of BulkOperations from the basic operations named CacheDriver. In a given class, I might want to only accept CacheDrivers that also support BulkOperations. How would I achieve that? The same happens to upper bounds that someone asked for an example privately. If I want to hire/move a person to a department that is registered in the system, but is not a 3rd party company person, how would you achieve that considering the following class structure? class Person {} class Employee extends Person {} class AssociateEmployee extends Employee {} class Manager extends Employee {} Considering your function: function assignToDepartment<T>(T $person) : bool; Generic type "T" in the function prototype needs to accept Person (new hire), Employee and Manager (transfer), but not AssociateEmployee. Considering upper bounds support only, your best bet is "T extends Person", but that would accept AssociateEmployee to be provided, which contradicts the business rule. Accepting anything lower in the hierarchy prevents new hires. That's when lower bounds comes into play. If you define as "T super Manager", all Person, Employee and Manager gets accepted, but not the AssociatedEmployee, matching properly the business rule. Also, someone else asked about type inference over my comment #4 in this example: class Foo<A> { public function __construct<B>(B $b) {} } $foo = new Foo<string>(1); The question asked is if that "string" was an inference over A or B. The correct answer is A, because generic type B is inferred from the parameter (integer) provided. That is exactly why class generic type definition should never be inferred from the constructor arguments, because you make it impossible to support both constructor generic types AND class generic type definitions at the same time.