Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88131
Return-Path: <me@stephencoakley.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 8719 invoked from network); 10 Sep 2015 01:50:45 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Sep 2015 01:50:45 -0000
X-Host-Fingerprint: 68.118.157.39 68-118-157-39.dhcp.mdsn.wi.charter.com  
Received: from [68.118.157.39] ([68.118.157.39:21313] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 5A/30-04930-4F1E0F55 for <internals@lists.php.net>; Wed, 09 Sep 2015 21:50:44 -0400
Message-ID: <5A.30.04930.4F1E0F55@pb1.pair.com>
To: internals@lists.php.net
References: <55E4B9AA.9060906@dasprids.de> <09.54.59944.CD76CE55@pb1.pair.com>
 <CADyq6sJjcz2hyPHEdSLowyBDqmDBp-Gb5rWC5VUpCZctwkB+1g@mail.gmail.com>
 <55ED68D2.9020508@dasprids.de>
 <CAFKLSKDk-=s8PCQnn3n9SO9RKF99M_=iw1XT_SP+FqnTirMCPA@mail.gmail.com>
Date: Wed, 9 Sep 2015 20:50:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAFKLSKDk-=s8PCQnn3n9SO9RKF99M_=iw1XT_SP+FqnTirMCPA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 68.118.157.39
Subject: Re: [PHP-DEV] Re: Generic classes and methods RFC
From: me@stephencoakley.com (Stephen Coakley)

On 09/07/2015 02:02 PM, George Bond wrote:
> On 7 September 2015 at 11:37, Ben Scholzen <mail@dasprids.de> wrote:
>
>> Hello,
>>
>> Hi Ben!
>>>
>>> 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.
>>>
>>
>> I'm not sure if we would need any other default than "mixed". Personally I
>> think that you should be able to instantiate any generic class which does
>> not enforce specific types on the hints without any types, which
>> automatically turns it into a mixed-type generic. That should cover this
>> use-case pretty easily.
>>
>> 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?
>>>
>>
>> As written in an earlier mail, the colon came up from another email, I'm
>> happy to change it if there's a better suggestion.
>>
>>
>> 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.
>>>
>>
>> I like that idea, as it makes the code easier to understand. I'm wondering
>> what other people's thoughts about that is.

You could also just use the dollar sign for type variables. As in

     class Entry<$KeyType, $ValueType>
     {
         // ...
         public function __construct($KeyType $key, $ValueType $value)
         {
             // ...
         }
         // ...
     }

Not sure if that would be *more* confusing or *less* confusing. If there 
was such a thing as a "type" type, then, depending on how generics were 
implemented, the type variables could *literaly* be "type" variables. If 
that makes any sense at all.

You could also have the type variables resolve to type strings somehow. 
For example, the output of:

     class Box<$T>
     {
         public function __construct($T $value)
         {
             // ...
         }

         public function printType()
         {
             print "$T\n";
         }
     }

     $box = new Box<\My\Object>(new \My\Object());
     $box->printType();

would be "My\Object". Just another idea; one that feels very "PHP-like" 
to me anyway. Other opinions?

>> 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!
>>>
>>
>> I hope so as well!
>>
>> Hope my thoughts are somewhat helpful.
>>>
>>> --
>>> Andrea Faulds
>>> http://ajf.me/
>>>
>>
>> --
>> Ben Scholzen
>> http://www.dasprids.de
>>
>>
> I'm a fan of the C# syntax for generics ("where" keyword).  I think the
> natural translation of that syntax to PHP would be:
>
> class ListOfLoggers<T> extends Enumerable<T> implements ArrayAccess
>      where T implements LoggerInterface
> {
>      ...
> }
>
> Ie you have "where <class>" and then a block in the same syntax as a normal
> class extends/implements declaration.  The full structure would be:
>
> class Foo<TFirst, TSecond> extends BaseClass<TFirst, AnotherClass>
> implements IGenericInterface<TSecond>, IOtherInterface
>      where TFirst extends OtherBaseClass implements IAnotherInterface
>      where TSecond extends YetAnotherBaseClass implements
> IYetAnotherInterface, IEvenMoreInterfaces
> {
>      ....
> }
>
> C# doesn't put a comma between where blocks, which usually catches me out.
> It's open to bikeshedding whether it would be sensible to require one here
> (after "implements IAnotherInterface"), and if so whether to allow a
> trailing comma (after "IEvenMoreInterfaces").
>
> Thoughts?
>
> --G
>

I like the "where" syntax as well. Most of PHP's "type operators" are 
words instead of glyphs, so it makes sense to keep the tradition for 
consistency. See the various syntaxes and keywords for using traits for 
comparison.

I think adding a comma between "where" expressions is a little 
redundant; I'd leave it out like in C#.

-- Stephen