Re: Generic classes and methods RFC

(Please stop top-posting!) On Fri, Sep 11, 2015 at 10:55 AM, Ben Scholzen <mail@dasprids.de> wrote: > Well, with the example, there's a good reason to have them separated: > > class Factory > { > public static function createFoo<T extends \SomeClass>() > { > return new Foo<T>(); > } > > public static function createBar<T extends \SomeOtherClass>() > { > return new Bar<T>(); > } > } > > class Foo<T extends \SomeClass> {} > class Bar<T extends \SomeOtherClass> {} > > The factory instance does not know to need about <T>, this is purely a type > for the method to be able to create another class, which requires that type. > You couldn't put this definition on the Factory class. What would prohibit this? class Factory<T> { public static function makeFoo() { return new Foo<T>(); } } It's perhaps less generic than what you posted, but this demonstrates that that a Factory *could* hold the definition on the class and not the method. To be honest, I don't know why you would bother doing this anyway. I am a fan of realistic examples and Factories that make Foos of type T is pretty unrealistic.