Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <09.54.59944.CD76CE55@pb1.pair.com>
To: internals@lists.php.net
References: <55E4B9AA.9060906@dasprids.de>
Date: Sun, 6 Sep 2015 17:20:40 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Firefox/38.0 SeaMonkey/2.35
MIME-Version: 1.0
In-Reply-To: <55E4B9AA.9060906@dasprids.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: Generic classes and methods RFC
From: ajf@ajf.me (Andrea Faulds)

Hi Ben!

Ben Scholzen 'DASPRiD' wrote:
> Hello,
>
> I've written up an RFC for supporting generic classes and methods in
> PHP, and I'd love to hear your thoughts about it.
>
> https://wiki.php.net/rfc/generics
>
> Cheers,

Generics are a feature I'd love to see in PHP. I think this RFC could do 
with a little elaboration, though.

Something that's particularly important to me is if it be possible to 
have default values for type parameters? For example, could I make a 
class like this?

     <?php
     // note the =, a default value (like function parameters)
     class List<T=mixed>
     {
         private $array = [];

         // ...

         public function append(T $value) {
             $this->array[] = $value;
         }
     }

     $integerList = new List<int>; // only accepts integers
     $list = new List; // accepts any value

Here, 'mixed' means any type, like in the PHP manual or in Hack. We 
don't currently have a 'mixed' typehint since we don't need it (you can 
simply omit a typehint for a parameter or return type), but it would be 
useful here.

I'd like it if this was possible, because then you could make existing 
classes use generics without breaking compatibility. It's also more 
beginner-friendly: people who don't know about generics don't have to 
use them, if the class author has made this possible. This is in keeping 
with the "PHP way" where we don't require people to use type hints if 
they don't want them.

On a different note, I'm not sure I like the  `class Baz<Foo : \Bar>` 
syntax. For functions parameters, we put the type name before the 
variable name, e.g. `function foo(int $bar)`. So, could we do the same 
here, i.e. `class <\Bar Foo>`, for consistency?

Though that looks a little strange to me. It's two bare identifiers next 
to eachother (`\Bar Foo`), unlike function parameters where the second 
one has a dollar prefix (`\Bar $foo`). Perhaps type variables, like 
regular variables, should have some sort of sigil in PHP? This would 
make it more obvious that something is a type variable and not a class 
name. To take an example from your RFC, consider the following code snippet:

     class Entry<KeyType, ValueType>
     {
         // ...

         public function __construct(KeyType $key, ValueType $value)
         {
             // ...
         }

         // ...
     }

If we hadn't seen the class declaration at the top which makes `KeyType` 
and `ValueType` be type parameters, we might not realise they weren't 
ordinary classes or interfaces when we looked at `__construct`. The 
-Type suffix you've used helps a little, but that's a convention, and 
isn't guaranteed to be used. Also, in some existing projects, there 
might be classes with that suffix.

What if we use some sort of sigil here to make it clear? Say we used %:

class Entry<%KeyType, %ValueType>
{
     // ...

     public function __construct(%KeyType $key, %ValueType $value)
     {
         // ...
     }

     // ...
}

Now, without having to look at the class declaration, we can tell that 
`KeyType` isn't a class name, because it has % in front of it.

Anyway, all that being said: the big challenge with generics is really 
getting someone to do the nitty-gritty of implementing it. It's great 
that you've got an RFC written for this, but unless someone is willing 
to implement it, I fear it may go to waste. But you writing an RFC might 
inspire someone. There is hope!

Hope my thoughts are somewhat helpful.

--
Andrea Faulds
http://ajf.me/