{"action":"created","issue":{"url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/81","labels_url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/81/labels{/name}","comments_url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/81/comments","events_url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/81/events","html_url":"https://github.com/phpDocumentor/fig-standards/pull/81","id":83701792,"number":81,"title":"add support for generics","user":{"login":"mindplay-dk","id":103348,"avatar_url":"https://avatars.githubusercontent.com/u/103348?v=3","gravatar_id":"","url":"https://api.github.com/users/mindplay-dk","html_url":"https://github.com/mindplay-dk","followers_url":"https://api.github.com/users/mindplay-dk/followers","following_url":"https://api.github.com/users/mindplay-dk/following{/other_user}","gists_url":"https://api.github.com/users/mindplay-dk/gists{/gist_id}","starred_url":"https://api.github.com/users/mindplay-dk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mindplay-dk/subscriptions","organizations_url":"https://api.github.com/users/mindplay-dk/orgs","repos_url":"https://api.github.com/users/mindplay-dk/repos","events_url":"https://api.github.com/users/mindplay-dk/events{/privacy}","received_events_url":"https://api.github.com/users/mindplay-dk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":35,"created_at":"2015-06-01T21:28:28Z","updated_at":"2015-08-17T06:10:59Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/phpDocumentor/fig-standards/pulls/81","html_url":"https://github.com/phpDocumentor/fig-standards/pull/81","diff_url":"https://github.com/phpDocumentor/fig-standards/pull/81.diff","patch_url":"https://github.com/phpDocumentor/fig-standards/pull/81.patch"},"body":"This is a preliminary draft adding support for generics."},"comment":{"url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/comments/131690845","html_url":"https://github.com/phpDocumentor/fig-standards/pull/81#issuecomment-131690845","issue_url":"https://api.github.com/repos/phpDocumentor/fig-standards/issues/81","id":131690845,"user":{"login":"pulyaevskiy","id":441756,"avatar_url":"https://avatars.githubusercontent.com/u/441756?v=3","gravatar_id":"","url":"https://api.github.com/users/pulyaevskiy","html_url":"https://github.com/pulyaevskiy","followers_url":"https://api.github.com/users/pulyaevskiy/followers","following_url":"https://api.github.com/users/pulyaevskiy/following{/other_user}","gists_url":"https://api.github.com/users/pulyaevskiy/gists{/gist_id}","starred_url":"https://api.github.com/users/pulyaevskiy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pulyaevskiy/subscriptions","organizations_url":"https://api.github.com/users/pulyaevskiy/orgs","repos_url":"https://api.github.com/users/pulyaevskiy/repos","events_url":"https://api.github.com/users/pulyaevskiy/events{/privacy}","received_events_url":"https://api.github.com/users/pulyaevskiy/received_events","type":"User","site_admin":false},"created_at":"2015-08-17T06:10:59Z","updated_at":"2015-08-17T06:10:59Z","body":"@mindplay-dk \r\nThanks for updating the PR with `@extends`. I think it fits a lot better here, though I'm still a bit worried about use cases like:\r\n```php\r\n<?php\r\n/**\r\n * @extends Bar<T>\r\n */\r\nclass Foo<T> implements Bar<T> {}\r\n```\r\nThis extends/implements juggling is kind of strange and confusing. \r\n\r\n> of course they're separate tags, they would be separate elements in a programming language with support for generics as well.\r\n\r\nBut right now `@extends` (former `@implements`) is limited only for use with generics, isn't it? However PHP defines those features (extend/implement) in a lot broader scope.\r\n\r\nThis can be fixed though by introducing both `@extends` and `@implements` as well as `@uses` and providing behaviors as those in the language itself. So depending on the use case we can use either `@implements SomeInterface<T>` or `@extends ClassOrInterface<T>` or `@uses SomeTrait<T>`.\r\n\r\n> the tags on `Iterable` shouldn't be redefining the generic signature of the parent `Iterator`\r\n\r\nNot sure I'm entirely following here, but I'll try to clarify.\r\n\r\nLets say we have `Iterator` interface defined like this (pseudo-code):\r\n```php\r\n<?php\r\ninterface Iterator<TKey, TValue> {}\r\n```\r\nIf I declare my own interface extending `Iterator` then proper syntax should be:\r\n```php\r\n<?php\r\ninterface Sequence<TElement> extends Iterator<int, TElement> {}\r\n```\r\nSo `Sequence` interface has one type parameter `TElement` which is mapped to `Iterator`'s type parameter `TValue`. So this is not \"redefining\" of signature of parent interface but rather defining of mapping between two signatures.\r\n\r\nIf we don't allow that, we are forcing all users to use built-in type aliases, which kind of defeats the purpose of type aliases. In Java, for instance, this is perfectly valid, as far as I know:\r\n```java\r\ninterface SomeGeneric<K, V> {}\r\ninterface SubtypeOfSomeGeneric<E> extends SomeGeneric<Integer, E> {}\r\n```\r\n\r\nNot sure if this makes sense, but I feel like it's important to avoid confusion on this topic.\r\n\r\n> that's going to create real problems with change management.\r\n\r\nQuite opposite based on my example above. The subject class or interface doesn't refer to parent class's type parameters therefore doesn't depend on name changes.\r\n\r\nSo as a summary, if nested tag I proposed seems rather overcomplicated:\r\n\r\n1. What about introducing both `@extends` and `@implements` (and probably `@uses` for traits) with exact semantics which we have in the language. Generic notation can be used in each of them based on the use case.\r\n2. If (1) is not an option, what about limiting scope of `@extends` to generics somehow explicitly. Either by something like `@generic extends Foo<T>` or some other syntax. For me option (1) seems more appropriate though.\r\n3. I think it's important to allow mapping of type parameters (type aliases) between current class/interface and it's parent."}}