Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVoe9WxNmLj0_N4HaOAmyyfMAp6yu0an6T5e9taZ2Raptg@mail.gmail.com>
References: <CADqTB_gUbfu91QRm1U0KyDjai8DKw7yCE6QxgUecy60oq3Zi8Q@mail.gmail.com>
 <CAKiSzdCO83XM0zqAeFnjQEMJvbd0yBmYAFnj0H6AtDumofVbkw@mail.gmail.com>
 <CAKiSzdCCEF=7OWtvZETG3bRoByCCLqEAEjuLW_H6m7MmDtJ8_g@mail.gmail.com>
 <CAFKaYMoQUUFLqgDjOHj3W0+a63u3s=vqnU5gWMCj0zvmvXFF5Q@mail.gmail.com>
 <3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net> <CAESVnVqCZnrbHa+5_tSYG70VyvGfpZoDM98bEst3pg36HahYEg@mail.gmail.com>
 <5716BB89.8030005@gmail.com> <CAESVnVoe9WxNmLj0_N4HaOAmyyfMAp6yu0an6T5e9taZ2Raptg@mail.gmail.com>
Date: Tue, 19 Apr 2016 22:54:21 -0400
Message-ID: <CAFp73Xvrh3xKvYs4RZ_mxhL+6+ppm3mdpfV6vdfYv8CLEQ9wxg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0883e01c08b30530e1b7b8
Subject: Re: [PHP-DEV] [RFC:generics]
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--94eb2c0883e01c08b30530e1b7b8
Content-Type: text/plain; charset=UTF-8

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:

> On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
> >> class Collection<T as (Traversable | Countable)> {...
> >
> > I am sorry if this sounds harsh, but I really hope we won't have
> > something like this in PHP. Java templates are complex and weird enough,
> > adding another layer on top of that to allow type expressions IMHO is
> > really taking it too far.
> >
> Nah, I've yet to actually have use for anything so specific yet
> either, but in the context of Mathieu was asking for, it seemed like a
> good moment to direct the concept back to something more consistent,
> at least.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Guilherme Blanco
Lead Architect at E-Block

--94eb2c0883e01c08b30530e1b7b8--