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?
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
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
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
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
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
--
--
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
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.
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
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
--
--
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
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: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
On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote: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
--
--
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
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
- Makes language harder to maintain as there is more (and more complex) code implementing it.
- Makes documentation bigger so users have first to figure out what part to read and what part to ignore.
- 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.
- Makes it harder to have extensions like APC as they have to implement more features.
- Makes it harder to write alternative implementations.
...
So yes, I agree with Rasmus that this is not a good fit for PHP.
- Chris
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
<skip> > So, what you think?Hello, list. I want to propose generics.
I'm against having this in PHP.
For IDEs, the better solution is to use generics-like syntax in docblocks.
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> > So, what you think?Hello, list. I want to propose generics.
I'm against having this in PHP.
For IDEs, the better solution is to use generics-like syntax in docblocks.
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: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"
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
:)
- Makes language harder to maintain as there is more (and more complex)
code implementing it.- Makes documentation bigger so users have first to figure out what
part to read and what part to ignore.- 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.- Makes it harder to have extensions like APC as they have to implement
more features.- 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.
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
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!
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
Stas,
On Sun, Oct 21, 2012 at 12:51 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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
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...
Hi,
Stas,
On Sun, Oct 21, 2012 at 12:51 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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 JavaThis 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
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.
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.
Hi,
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.
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
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,
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.
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
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
Hi,
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.
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
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:
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,
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.
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
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
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
Hi,
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.
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
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
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
Hi,
On Tue, Oct 23, 2012 at 4:17 AM, Levi Morrison <
morrison.levi@gmail.com> wrote: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.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
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
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
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 :)