Generic classes and methods RFC

On Mon, Aug 31, 2015 at 10:31 PM, Ben Scholzen 'DASPRiD'
mail@dasprids.de 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,

Ben Scholzen 'DASPRiD'
Community Review Team Member | mail@dasprids.de
Zend Framework | http://www.dasprids.de

--

Hello,

I would love to see generics in PHP, but I have a few questions for your
RFC.

class Bazz<Foo : \Bar>

Why did you use this syntax for forcing extending/implementation? I
know this is the syntax C# uses, but it doesn't fit PHP. I think it
should be "extends" or "implements", because in PHP : has a different
meaning.

Also, how do you specify multiple constraints?

Do you have any idea how it would work internally and if there was
some performance hit while using generics, and if it would also slow
down existing apps that don't use generics?

I hope this RFC will have positive comments, and someone who is
capable of writing C will help you out with it so there's a patch for
people to review - because I'm not sure if this RFC can get anywhere
without a patch. :(

Regards
Pavel Kouril

--

Hi Ben,

Now that I have substantive questions, including the list :)

In the following:

class SomeList<Bar> {
public static function fromArray<Baz>(array $a): SomeList<Baz> {
$list = new SomeList<Baz>();
$list2 = new SomeList<Bar>();
return $list;
}
}

$list = SomeList<int>::fromArray([1, 2]);

When fromArray() executes, what type is $list2? or is that an error? If
it's an error, what advantage is there to having distinct generic types on
the class vs. the method? How do I specify the two generic types I want to
use?

Another thing I'd like to make sure I understand, how does this interact
with strict types (and non-strict)?

new Entry<int, string>(1, 2);//I assume it should type-juggle

declare(strict_types = 1);
new Entry<int, string>(1, 2);//I assume it should throw error

I'm interested to see if PHP can get generics going. I hope hashing out
some more details might garner more interest.

Thanks,
John

Hi,

I would love to see generics in PHP, but I have a few questions for your RFC.

class Bazz<Foo : \Bar>

Why did you use this syntax for forcing extending/implementation? I
know this is the syntax C# uses, but it doesn't fit PHP. I think it
should be "extends" or "implements", because in PHP : has a different
meaning.

I've used a different syntax before (namely "extends" and "implements"),
but someone pointed out, that a keyword-less version would make more
sense, so I updated it appropriately. If someone has a better
suggestion, I'm happy to include it in the RFC.

Also, how do you specify multiple constraints?

I didn't plan on covering multiple constraints here, as we don't handle
them at all in PHP yet. Although I've read that someone wanted to have
Union-types in PHP, which could be used here as well I suppose.

Do you have any idea how it would work internally and if there was
some performance hit while using generics, and if it would also slow
down existing apps that don't use generics?

I don't have enough insights in the PHP guts to make a good suggestion
about this, but I'd assume that it should not have a negative
performance effect on code which doesn't use generics.

I hope this RFC will have positive comments, and someone who is
capable of writing C will help you out with it so there's a patch for
people to review - because I'm not sure if this RFC can get anywhere
without a patch. :(

Regards
Pavel Kouril

--
Ben Scholzen
http://www.dasprids.de

Andrea Faulds wrote on 06/09/2015 17:20:

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.

As I understand it, the convention in a lot of languages is that type
parameters are a single upper-case letter. I'm not sure if any enforce
this restriction, though, and a sigil does seem more flexible and readable.

Regards,

Rowan Collins
[IMSoP]

Hi Dennis,

thanks for your feedback, see my answers below:

1. static methods:

class Foo<T> {
public static function test() {
}
}

how can I call the method:
a) Foo::test()
or
b) Foo<int>::test()

in case b), would the generic methods not be a duplication?

Case a) is correct here. A static method is not in the context of an
instance, so it doesn't know about the class boxing by itself.

2. Generic methods

a) Can generic methods be inside classes that themselves are not generic?

Sure, that's perfectly valid.

class Foo<T1> {
public static function test<T2>() {
$a = new self<T1>();
}
}

b) Is the generic parameter type of T1 set inside the static method or
only T2? And if T1 is available, why is T2 required? What is the
advantage of having T1 and T2?

T1 is not available in the static method, as said before, the static
method is not part of an instance. Furthermore, line 3 should read like
this:

$a = new self<T2>();

3. Class names

a) Is it possible to have two classes with the same name (in the same
namespace) but one that requires type parameters and one that does not?

That is in fact an implementation detail, but I'd tend to say no. That
is similar to function overloading, which we don't have in PHP (sadly).

b) Is it possible to allow for a generic class to be constructed without
type parameters (e.g. with mixed as the default)?

As I wrote in an earlier email, that would totally possible. My idea
there was, that, as long as the types don't have restrictions (to extend
another class or implement an interface), it should be allowed to
construct it without a type so that it accepts any parameters.

4. Reflection

Can you get the type parameters used to construct an object at runtime? How?

That's in fact an implementation detail I can't say anything about, sorry.

5. Implementation

How do you propose to implement all this? In Java (at least in older
versions, may have changed), generics where a pure compile time
function. So the compiler checked that your code did not validate the
type but you could not access the type parameter information it at
runtime. That is not possible for PHP. So either we need classes that
can be parameterized inside the PHP core or we need "template" classes
that are compiled into concrete implementations using the type
parameters once they are used first. Have you thought about which
variant you prefer and why (or any other I did forget)? Is this even
possible without digging deep inside the language?

I haven't thought about a concrete implementation, simply because I'm
not familiar enough with this part of the PHP core, and I'd leave it up
to someone else to suggest the best way to implement it. But the idea of
template classes sounds like a solution I'd probably chose if I didn't
know better… which I don't :)

Again, thanks for your feedback!

Ben Scholzen 'DASPRiD'
Community Review Team Member | mail@dasprids.de
Zend Framework | http://www.dasprids.de

Am 12.09.2015 um 12:03 schrieb Dennis Birkholz:

Hi together,

1. If we require some keyword instead of the colon to limit which types
   the type placeholders can have I would choose:
   class Foo<T1 instanceof Bla, T2 instanceof Blubb> {}

Just to save you some lookups in the Hack documentation:

1. Hack uses the "as" keyword:
   class Foo<T1 as Bla> {}

2. It does not allow to require multiple types for T1:
   "Currently, Hack only allows one constraint on a type or a method."

3. I found no example that Hack allows multiple type parameters like
   class Foo<T1, T2> but also nothing that it is not possible

4. All type parameters must start with a capital T

5. Hack has generic methods

6. Hack has generic traits which we should also consider/specify how
   they work exactly.

Greets
Dennis

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