# Generics proposal

- Thread: https://externals.io/message/63573
- Original archive: https://news-web.php.net/php.internals/63573
- Started by Nikita on 2012-10-20T20:59:01+00:00
- Messages: 25
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #63573 — Nikita — 2012-10-20T20:59:01+00:00

URL: https://externals.io/message/63573#63573

Hello, list. I want to propose generics. For those, who don't know what it is, here's example: say we have a Comment class, that has a method getBody. Also we have Collection class, that implements Traversable. Now, if I want to validate all insertions into collection of comments, I would need to create CommentCollection class, extend it from Collection, and override all the methods that are dealing with adding new elements to collection. Moreover, I can't have any hints from my IDE about type of collection's elements, so if I'll have code like this:
foreach ($commentCollection as $comment) {
    $comment->getBody();
}
There will be no way for IDE to know, of what type that object will be.

But there's how I could solve my problem with generics:
class Collection<T> implements Traversable
{
    ...
    public function add(T $element){}
}
$collection = new Collection<Comment>();

$collection->add(new Comment());

$collection->add("that will be error");

Actually, that's, again, all about type hinting. If we went so far with scalar type hinting, then generics would also be a good addition.

So, what you think?

---

## #63574 — Rasmus Lerdorf — 2012-10-20T21:02:00+00:00

URL: https://externals.io/message/63573#63574 · In reply to: #63573

> Hello, list. I want to propose generics. For those, who don't know what it is, here's example: say we have a Comment class, that has a method getBody. Also we have Collection class, that implements Traversable. Now, if I want to validate all insertions into collection of comments, I would need to create CommentCollection class, extend it from Collection, and override all the methods that are dealing with adding new elements to collection. Moreover, I can't have any hints from my IDE about type of collection's elements, so if I'll have code like this:
> foreach ($commentCollection as $comment) {
>     $comment->getBody();
> }
> There will be no way for IDE to know, of what type that object will be.
> 
> But there's how I could solve my problem with generics:
> class Collection<T> implements Traversable
> {
>     ...
>     public function add(T $element){}
> }
> $collection = new Collection<Comment>();
> 
> $collection->add(new Comment());
> 
> $collection->add("that will be error");
> 
> Actually, that's, again, all about type hinting. If we went so far with scalar type hinting, then generics would also be a good addition.
> 
> So, what you think?

Personally I would hate to see this anywhere near PHP.

-Rasmus

---

## #63575 — Michael Stowe — 2012-10-20T21:09:50+00:00

URL: https://externals.io/message/63573#63575 · In reply to: #63574

I see what you're trying to do but not a big fan of how it's being implemented in the example given. 

- Mike

Sent from my iPhone



> 
> > […]
> 
> Personally I would hate to see this anywhere near PHP.
> 
> -Rasmus

---

## #63576 — Marco Pivetta — 2012-10-20T22:10:58+00:00

URL: https://externals.io/message/63573#63576 · In reply to: #63575

> I see what you're trying to do but not a big fan of how it's being
> implemented in the example given.
>
> - Mike
>
> Sent from my iPhone
>
> 
>
> > […]
> it is, here's example: say we have a Comment class, that has a method
> getBody. Also we have Collection class, that implements Traversable. Now,
> if I want to validate all insertions into collection of comments, I would
> need to create CommentCollection class, extend it from Collection, and
> override all the methods that are dealing with adding new elements to
> collection. Moreover, I can't have any hints from my IDE about type of
> collection's elements, so if I'll have code like this:
> > […]
> scalar type hinting, then generics would also be a good addition.
> > […]
>
> --
> 
> 
>
>
Well, the example just shows what I've already got used to when working
with Java.
I like it and it would be of great help to me (especially in reducing the
amount of code to be tested), but there's a lot more around that, like
multiple generic types (new Map<Comment, User>()) and how reflection would
deal with it...

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #63578 — Paul Dragoonis — 2012-10-21T11:24:14+00:00

URL: https://externals.io/message/63573#63578 · In reply to: #63576

Hi Nikita,

What you're asking for is useful in other languages, but it doesn't match
the style of PHP which is to be a quick and easy type-less scripting
language.

What you're proposing is clearly more suited to something like Java or C#,
but doesn't really belong here.

I'd also hate to see this anywhere near PHP.

Many thanks,
Paul.



> 
>
> > […]
> what
> > […]
> be.
> > […]
> with
> > […]
> Well, the example just shows what I've already got used to when working
> with Java.
> I like it and it would be of great help to me (especially in reducing the
> amount of code to be tested), but there's a lot more around that, like
> multiple generic types (new Map<Comment, User>()) and how reflection would
> deal with it...
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/

---

## #63579 — Nikita Nefedov — 2012-10-21T11:33:56+00:00

URL: https://externals.io/message/63573#63579 · In reply to: #63578

No, this is useful in any OOP-language where there is such thing as type,  
and people need to validate types.
I unerstand what you are saying about PHP being an easy language, but in  
opinion if you don't want to use that feature you can not use it, as you  
can not use typehinting in functions for example.


> Hi Nikita,
>
> What you're asking for is useful in other languages, but it doesn't match
> the style of PHP which is to be a quick and easy type-less scripting
> language.
>
> What you're proposing is clearly more suited to something like Java or  
> C#,
> but doesn't really belong here.
>
> I'd also hate to see this anywhere near PHP.
>
> Many thanks,
> Paul.
>
> On Sat, Oct 20, 2012 at 11:10 PM, Marco Pivetta <ocramius@gmail.com>  
> wrote:
>
> > […]

---

## #63580 — Alexey Zakhlestin — 2012-10-21T11:55:23+00:00

URL: https://externals.io/message/63573#63580 · In reply to: #63573

> Hello, list. I want to propose generics. 
<skip>
> So, what you think?

I'm against having this in PHP.

For IDEs, the better solution is to use generics-like syntax in docblocks.

---

## #63581 — Christian Schneider — 2012-10-21T12:39:37+00:00

URL: https://externals.io/message/63573#63581 · In reply to: #63579

Am 21.10.2012 um 13:33 schrieb Nikita Nefedov <inefedor@gmail.com>:
> No, this is useful in any OOP-language where there is such thing as type, and people need to validate types.

I question the "need to validate" types part. I'd say you're better off using a completely different language if you want to use strong typing. For PHP: Embrace duck typing, write less boiler-plate code (thus reducing the need for "smart" IDE) and be happy :-)

> I unerstand what you are saying about PHP being an easy language, but in opinion if you don't want to use that feature you can not use it, as you can not use typehinting in functions for example.

That's the same as saying you can ignore most of the C++ feature and that will make it a simple language. That's neither true for developers nor users of the language.

Example on why this is are
1) Makes language harder to maintain as there is more (and more complex) code implementing it.
2) Makes documentation bigger so users have first to figure out what part to read and what part to ignore.
3) Makes it harder to write portable user-land libraries as the application and the different libraries might use different (clashing) paradigms. See error codes vs. exceptions as an example of this.
4) Makes it harder to have extensions like APC as they have to implement more features.
5) Makes it harder to write alternative implementations.
...

So yes, I agree with Rasmus that this is not a good fit for PHP.

- Chris

---

## #63582 — Devis Lucato — 2012-10-21T12:45:24+00:00

URL: https://externals.io/message/63573#63582 · In reply to: #63580

I see what you are trying to achieve, but I hope this will never make into
PHP mainly for impact on readability.  I'd like to quote Eric Armstrong, a
passionate Java/Ruby dev:

> I decry their very existence. They are the ultimate condemnation of
static
> type checking--because their very addition has virtually destroyed both
the
> readability and elegance of the language.
> To make my case, let's start with a quasi-mathematical definition of
"elegance".
> In my view, elegance is a function of power and simplicity. Power is
measured
> by how much you can do. Simplicity is the inverse of the number of
characters
> it takes to achieve the result. So more power with fewer characters
equals
> "elegance"

http://www.artima.com/weblogs/viewpost.jsp?thread=299081


Devis




>
> 
>
> > […]
> <skip>
> > […]
>
> I'm against having this in PHP.
>
> For IDEs, the better solution is to use generics-like syntax in docblocks.

---

## #63583 — Nikita Nefedov — 2012-10-21T13:22:08+00:00

URL: https://externals.io/message/63573#63583 · In reply to: #63582

I actually don't have much experience with generics, so won't argue about  
their readability, but this article is all about Java's implementation of  
generics, so I don't know how much sense this article gives in that  
context.
But it's ok, I see just one person that supported proposal. I think case  
closed.

> I see what you are trying to achieve, but I hope this will never make  
> into
> PHP mainly for impact on readability.  I'd like to quote Eric Armstrong,  
> a
> passionate Java/Ruby dev:
>
> > […]
> static
> > […]
> the
> > […]
> "elegance".
> > […]
> measured
> > […]
> characters
> > […]
> equals
> > […]
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=299081
__________________

> I question the "need to validate" types part. I'd say you're better off  
> using a completely different language if you want to use strong typing.  
> For PHP: Embrace duck typing, write less boiler-plate code (thus  
> reducing the need for "smart" IDE) and be happy :-)

We have typehints, that was my point here.

> That's the same as saying you can ignore most of the C++ feature and  
> that will make it a simple language. That's neither true for developers  
> nor users of the language.

PHP now is multi-paradigm language (isn't it), so... yep, that's the same  
:)

> 1) Makes language harder to maintain as there is more (and more complex)  
> code implementing it.
> 2) Makes documentation bigger so users have first to figure out what  
> part to read and what part to ignore.
> 3) Makes it harder to write portable user-land libraries as the  
> application and the different libraries might use different (clashing)  
> paradigms. See error codes vs. exceptions as an example of this.
> 4) Makes it harder to have extensions like APC as they have to implement  
> more features.
> 5) Makes it harder to write alternative implementations.

All this points are also applicable to namespaces, [abstract,final]  
classes, interfaces, traits, access modifiers (instead of using `var`),  
etc.
If you would have said, this points in the context of... say... necessity  
of that feature, then yeah, maybe you would be right.

Anyway, as long as almost no one didn't supported, I think we can close  
this discussion.

---

## #63590 — Lars Strojny — 2012-10-21T15:39:36+00:00

URL: https://externals.io/message/63573#63590 · In reply to: #63574

Hi Rasmus,

Am 20.10.2012 um 23:02 schrieb Rasmus Lerdorf <rasmus@lerdorf.com>:
[...]
> Personally I would hate to see this anywhere near PHP.

Do you mind explaining the why? Isn’t it better than new Collection("TypeAsAString") and custom assertions in each and every method of that collection class?

cu,
Lars

---

## #63591 — Stas Malyshev — 2012-10-21T16:51:40+00:00

URL: https://externals.io/message/63573#63591 · In reply to: #63573

Hi!

> Hello, list. I want to propose generics.

Please no. If you need Java, you know where to find it. Java has a set
of great tools, great books, great community. And it's completely free.
Anybody who needs Java can just do it. I see no need to turn PHP into Java.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #63598 — Amaury Bouchard — 2012-10-22T09:26:51+00:00

URL: https://externals.io/message/63573#63598 · In reply to: #63591

Nobody wants to turn PHP into Java.

But, even if I agree for generics (or templates), I would like to know
where is the border line.

Classes, exceptions, interfaces, traits, type hinting in parameters => OK
Type hinting in object properties, type hinting of returned values, type
templating => KO?

Maybe we'd save time if it was clearly defined (and accept my apologies if
it was already defined somewhere).


2012/10/21 Stas Malyshev <smalyshev@sugarcrm.com>

> Hi!
>
> > […]
>
> Please no. If you need Java, you know where to find it. Java has a set
> of great tools, great books, great community. And it's completely free.
> Anybody who needs Java can just do it. I see no need to turn PHP into Java.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #63600 — jpauli — 2012-10-22T16:25:48+00:00

URL: https://externals.io/message/63573#63600 · In reply to: #63573

> Hello, list. I want to propose generics. For those, who don't know what it is, here's example: say we have a Comment class, that has a method getBody. Also we have Collection class, that implements Traversable. Now, if I want to validate all insertions into collection of comments, I would need to create CommentCollection class, extend it from Collection, and override all the methods that are dealing with adding new elements to collection. Moreover, I can't have any hints from my IDE about type of collection's elements, so if I'll have code like this:
> foreach ($commentCollection as $comment) {
>     $comment->getBody();
> }
> There will be no way for IDE to know, of what type that object will be.
>
> But there's how I could solve my problem with generics:
> class Collection<T> implements Traversable
> {
>     ...
>     public function add(T $element){}
> }
> $collection = new Collection<Comment>();
>
> $collection->add(new Comment());
>
> $collection->add("that will be error");
>
> Actually, that's, again, all about type hinting. If we went so far with scalar type hinting, then generics would also be a good addition.
>
> So, what you think?


Hah, I had the use case often, and every OO programmer has met this
use case several time I think :
Here is an example with SplObjectStorage (which is a good starting
point structure for that) :

<?php
class MyClass extends SPlObjectStorage
{
    public function attach(MyType $o, $data = null) { /* throws an
 `E_STRICT` we all know about */
        return parent::attach($o, $data);
    }
}

Solution :

<?php
class MyClass extends SPlObjectStorage
{
    public function attach($o, $data = null) {
        if (!$o instanceof MyType) {  /* That is both ugly and boring
to write */
            throw new \RuntimeException();
        }
        return parent::attach($o, $data);
    }
}

So, I'm +1 with the idea, but -1 with the proposed syntax.

I'm +1 with Lars, as this can be done with a "TypeAsString", this is
as well ugly, and I think we need PHP to provide a way to do that :

<?php
class Foo
{
    public function __construct($type) { $this->type = $type; }

    public function add($o)
    {
        if (!$o instanceof $this->type) {
            throw new \RunTimeException("type {$this->type} expected");
        }
        /* do something with $o*/
    }
}
class Bar { }
class Baz { }

$f = new Foo('bar');
$f->add(new Bar); /* OK */
$f->add(new Baz); /* KO */
$f->add(array()); /* KO */
?>

IMO : this is something the language should take care of, not the
developper, but that's my opinion :)

---

## #63602 — Anthony Ferrara — 2012-10-22T19:44:40+00:00

URL: https://externals.io/message/63573#63602 · In reply to: #63591

Stas,

On Sun, Oct 21, 2012 at 12:51 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > […]
>
> Please no. If you need Java, you know where to find it. Java has a set
> of great tools, great books, great community. And it's completely free.
> Anybody who needs Java can just do it. I see no need to turn PHP into Java
>

This is not about turning PHP into Java. Can we get over that old rhetoric
already? Instead of bashing proposals like this, can we discuss them,
instead of this hatred for all things strict?

With that aside, I have mixed feelings on this.

On the one hand, I love the functionality. The ability to have
meta-type-safety without having to pollute the environment with tons of
empty classes with nothing more than a type hint (for all collection types)
is huge. It would definitely make defensive programming much easier.
Especially if the ability was afforded to arrays as well (function
foo(array<Bar> $array){})...

On the other hand, the syntax leaves a lot to be desired. It's quite
confusing and really is ugly. As far as how to fix the syntax, I'm not sure.

But I would like to voice my support for the concept...

---

## #63603 — Etienne Kneuss — 2012-10-22T22:14:43+00:00

URL: https://externals.io/message/63573#63603 · In reply to: #63602

Hi,


> Stas,
>
> On Sun, Oct 21, 2012 at 12:51 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
>
> > […]
>
> This is not about turning PHP into Java. Can we get over that old rhetoric
> already? Instead of bashing proposals like this, can we discuss them,
> instead of this hatred for all things strict?
>
> With that aside, I have mixed feelings on this.
>
> On the one hand, I love the functionality. The ability to have
> meta-type-safety without having to pollute the environment with tons of
> empty classes with nothing more than a type hint (for all collection types)
> is huge.

Let's not talk about type safety, there is nothing that is type-safe here.
What this proposal is describing is syntactic sugar for runtime type
checks (which is exactly what type hints are anyway).

The arguments for and against runtime type checks are the same that
they were 5 years ago: unlike other languages that support generics:
PHP will have: no compiler support => no static guarantees => runtime,
unnexpected errors.

The argument should really be whether the cost of having that syntax
in the language is less than the benefits of catching such errors
"early" (early being usually one stack frame earlier, but I have no
definite stats on that).

> It would definitely make defensive programming much easier.
> Especially if the ability was afforded to arrays as well (function
> foo(array<Bar> $array){})...

This would require O(n) runtime tests, I would definitely not go there.

>
> On the other hand, the syntax leaves a lot to be desired. It's quite
> confusing and really is ugly. As far as how to fix the syntax, I'm not sure.
>
> But I would like to voice my support for the concept...



-- 
Etienne Kneuss
http://www.colder.ch

---

## #63604 — Christian Schneider — 2012-10-22T22:57:37+00:00

URL: https://externals.io/message/63573#63604 · In reply to: #63602

Am 22.10.2012 um 21:44 schrieb Anthony Ferrara <ircmaxell@gmail.com>:
> This is not about turning PHP into Java. Can we get over that old rhetoric
> already? Instead of bashing proposals like this, can we discuss them,
> instead of this hatred for all things strict?
> 
> With that aside, I have mixed feelings on this.

… and while it might not be about turning PHP into Java it might still be worthwhile to read a bit about experiences with Generics in Java: http://www.artima.com/weblogs/viewpost.jsp?thread=299081

Basically it means that you type more (redundant) stuff to allow the compiler to check some errors.
And while type hints and PPP are along the same line I think the main difference is that they put the burden on the declarations, not on the users of an API.

That said I'm not even using type hints of PPP and sometimes it would be handy if internal functions would be less strict about their parameters (e.g. `debug_backtrace()` not accepting two arguments in PHP < 5.4 and return null in that case instead of silently ignoring the extra parameter).

- Chris

---

## #63605 — johannes@schlueters.de — 2012-10-22T23:32:33+00:00

URL: https://externals.io/message/63573#63605 · In reply to: #63604

> 
> Basically it means that you type more (redundant) stuff to allow the
> compiler to check some errors.

Which we can't do due to PHP's dynamic nature. For the engine to take
benefit from it we'd have to change the language.

All we do,when implementing such a feature is adding a default way so
IDEs and other tools can do their checks and to enforce specific
runtime(!) errors (while in effect all it does is swap one kind of error
(fatal error, not existing function) for another (so called "catchable"
error, wrong type)) at the cost of making some operations, at least
function calls, more expensive (more things to check at runtime - has a
small impact even when not used ... and that while our fcalls are
already relatively expensive ...)

johannes

---

## #63606 — Levi Morrison — 2012-10-23T02:17:03+00:00

URL: https://externals.io/message/63573#63606 · In reply to: #63603

> > […]
>
> This would require O(n) runtime tests, I would definitely not go there.

Actually, it does not require O(n) runtime tests.  The solution is
simple: store the type when it is created. Whenever an element is
added, make sure it matches the correct type.  All this does is add
some flat overhead.

I am also supportive of the idea of having generics, but I am not sure
that the work it would take is worth it.

---

## #63607 — Etienne Kneuss — 2012-10-23T11:21:49+00:00

URL: https://externals.io/message/63573#63607 · In reply to: #63606

Hi,


> > […]
>
> Actually, it does not require O(n) runtime tests.  The solution is
> simple: store the type when it is created. Whenever an element is
> added, make sure it matches the correct type.  All this does is add
> some flat overhead.

If you test every time you add one element, that's still O(n) tests
where n is the size of the array, the only benefit is that it is not
checked for each calls to a function. But now we are talking about
attaching non-trivial types to variables, and non-trivial checks in a
lot of places (think references etc..), let's not go there...

>
> I am also supportive of the idea of having generics, but I am not sure
> that the work it would take is worth it.



-- 
Etienne Kneuss
http://www.colder.ch

---

## #63754 — Sara Golemon — 2012-11-06T03:14:26+00:00

URL: https://externals.io/message/63573#63754 · In reply to: #63607

Sorry to be late to the conversation, but fwiw, HipHop is adding
Generics (and some other cool things) to our PHP implementation.  We
plan to provide a PHP equivalent implementation in the form of a
pre-processor extension which can live in PECL.  The implementation
would of course be cleaner if done directly in the engine, but with
APC the performance hit of doing an extra transformation pass should
disappear. Hopefully this satisfies both the want for Java/C++-like
syntax without "polluting" the language.

-Sara


> Hi,
>
> 
> > […]
>
> If you test every time you add one element, that's still O(n) tests
> where n is the size of the array, the only benefit is that it is not
> checked for each calls to a function. But now we are talking about
> attaching non-trivial types to variables, and non-trivial checks in a
> lot of places (think references etc..), let's not go there...
>
> > […]
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch

---

## #63767 — Lars Strojny — 2012-11-06T20:50:58+00:00

URL: https://externals.io/message/63573#63767 · In reply to: #63754

Hey Sara,

can you already show us how your take on Generics would look like? Maybe this is a good moment for HipHop and PHP to do something together.

Am 06.11.2012 um 04:14 schrieb Sara Golemon <pollita@php.net>:

> Sorry to be late to the conversation, but fwiw, HipHop is adding
> Generics (and some other cool things) to our PHP implementation.  We
> plan to provide a PHP equivalent implementation in the form of a
> pre-processor extension which can live in PECL.  The implementation
> would of course be cleaner if done directly in the engine, but with
> APC the performance hit of doing an extra transformation pass should
> disappear. Hopefully this satisfies both the want for Java/C++-like
> syntax without "polluting" the language.
> 
> -Sara
> 
> 
> > […]

---

## #63771 — Sara Golemon — 2012-11-07T05:41:55+00:00

URL: https://externals.io/message/63573#63771 · In reply to: #63767

Retrying this with reply-to-all. :)

I think it's an awesome moment for PHP and HipHop to work together! :)
 I'll summarize what we have so far into an RFC.

-Sara


> Hey Sara,
>
> can you already show us how your take on Generics would look like? Maybe this is a good moment for HipHop and PHP to do something together.
>
> Am 06.11.2012 um 04:14 schrieb Sara Golemon <pollita@php.net>:
>
> > […]

---

## #63775 — Lars Strojny — 2012-11-07T14:00:41+00:00

URL: https://externals.io/message/63573#63775 · In reply to: #63771

Cool! Looking forward to it.

Am 07.11.2012 um 06:41 schrieb Sara Golemon <pollita@php.net>:

> Retrying this with reply-to-all. :)
> 
> I think it's an awesome moment for PHP and HipHop to work together! :)
> I'll summarize what we have so far into an RFC.
> 
> -Sara
> 
> 
> > […]

---

## #63882 — Jan Dolecek — 2012-11-15T15:39:26+00:00

URL: https://externals.io/message/63573#63882 · In reply to: #63771

Hi Sara, any progress with your RFC? Can't wait to see it.
Thanks

Jan Dolecek
juzna.cz@gmail.com




> Retrying this with reply-to-all. :)
>
> I think it's an awesome moment for PHP and HipHop to work together! :)
>  I'll summarize what we have so far into an RFC.
>
> -Sara
>
> 
> > […]
> this is a good moment for HipHop and PHP to do something together.
> > […]
> morrison.levi@gmail.com> wrote:
> > […]
> there.
> > […]
