Hello everyone,
I'm emailing to this list to suggest that "support for type-hinted
return values"[1] be in added in PHP 5.y.x instead of PHP 6.
Conceptually, this is the second half of "type-hints" already introduced
in PHP 5.
This is why: When a programmer is designing an interface (the language
construct), only what is accepted by the interface can be defined.
Calling code is left with no idea of what the return type is going to be.
Even with great documentation, when designing an interface, it would be
great to be able to take the responsibility of type checking return
values from calling code onto the interface. To design a full interface,
the interface designer should be able to say that a caller can call
method X with input types Y and Z, then expect an object that implements
interface Z to be returned. The caller should not have the
responsibility of handling any other return types.
I'm looking forward to many of the upcoming features of PHP6, but PHP 6
is far from being stable (?). This is a change will break any existing
code and is not a big extension on how PHP, a weakly typed language (not
necessarily a bad thing), handles types.
[1] http://oss.backendmedia.com/PhP60
ps - please let me know if posts like these should be posted elsewhere
Thanks,
David N. Q. Duong
Since there isn't any comments on this, should I have posted this
elsewhere? or is it just that no one is interested?
David Duong wrote:
Hello everyone,
I'm emailing to this list to suggest that "support for type-hinted
return values"[1] be in added in PHP 5.y.x instead of PHP 6.
Conceptually, this is the second half of "type-hints" already introduced
in PHP 5.This is why: When a programmer is designing an interface (the language
construct), only what is accepted by the interface can be defined.
Calling code is left with no idea of what the return type is going to be.Even with great documentation, when designing an interface, it would be
great to be able to take the responsibility of type checking return
values from calling code onto the interface. To design a full interface,
the interface designer should be able to say that a caller can call
method X with input types Y and Z, then expect an object that implements
interface Z to be returned. The caller should not have the
responsibility of handling any other return types.I'm looking forward to many of the upcoming features of PHP6, but PHP 6
is far from being stable (?). This is a change will break any existing
code and is not a big extension on how PHP, a weakly typed language (not
necessarily a bad thing), handles types.[1] http://oss.backendmedia.com/PhP60
ps - please let me know if posts like these should be posted elsewhere
Thanks,
David N. Q. Duong
Since there isn't any comments on this, should I have posted this
elsewhere? or is it just that no one is interested?
It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decision?
--
troels
Since there isn't any comments on this, should I have posted this
elsewhere? or is it just that no one is interested?It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decision?
Most likely no developer with enough knowledge had the
motivation/need/whatever to sit down and implement this. Don't forget
that most work on PHP is done on a voluntary basis so some features
which might look interesting for a few users might have lower priority
for developers.
To the original question: The patch might be applied to a 5.3 branch,
maybe. Not to 5.2 since it would break BC. A 5.3 branch is not yet
planned so there's no decision about what is being merged there from
head or not.
johannes
It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decision?
I think it's design one since nobody took care to design it :) I
personally don't see much need for it, since PHP is not a compiled
language, so there's little use for specific syntax of prescribing value
types. Since PHP has no concept of variable type, it's not clear what
return type hinting would give you that good documenting practices and a
decent IDE won't.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
It would give you similar benefits to input type hinting, but instead of
"Functions are now able to force parameters to be objects...", it would
also read "Calling functions are now able to expect return types to be
objects...". If a function was defined to return object Z, but instead
returned false, then obviously there is something wrong and it could be
caught before calling code sees it expecting it to be something else.
This feature does not replace good documentation, good testing, or
provide any new functionality that could not be recreated by other
means. However, it provides a different and often better solution to
common problems. Many current PHP projects already have some sort of
"module" or "plugin" system how they make use of modules and return type
checking (if at all) vary wildly. With THRs future projects would be
able to make use of a slightly more advanced language with better
support for modular programming.
If I, or someone else decided to make a patch for this, and assuming it
worked exactly like I described, would it be accepted?
Stanislav Malyshev wrote:
It could be interesting to know, if the reason why this hasn't been
implemented already, is technical one, or a design decision?I think it's design one since nobody took care to design it :) I
personally don't see much need for it, since PHP is not a compiled
language, so there's little use for specific syntax of prescribing value
types. Since PHP has no concept of variable type, it's not clear what
return type hinting would give you that good documenting practices and a
decent IDE won't.
It would give you similar benefits to input type hinting, but instead of
"Functions are now able to force parameters to be objects...", it would
also read "Calling functions are now able to expect return types to be
objects...". If a function was defined to return object Z, but instead
returned false, then obviously there is something wrong and it could be
caught before calling code sees it expecting it to be something else.
Catching language-level error in application code is usually harder than
just handling it in user code. And if you are talking about distinction
between false/null and actual object, language level is the wrong level
to catch such things.
If you handle the error in runtime, you could have the check as well. If
you don't, the script breaks anyway, so it is not going to help you much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm going
to process only type X, and I make a requirement for others to pass only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in dynamic
interpreted languages.
Also, since from the client side there's no way to check if the function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.
If I, or someone else decided to make a patch for this, and assuming it
worked exactly like I described, would it be accepted?
I don't know... I personally don't see much use for it, but others may
disagree.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
It would give you similar benefits to input type hinting, but instead of
"Functions are now able to force parameters to be objects...", it would
also read "Calling functions are now able to expect return types to be
objects...". If a function was defined to return object Z, but instead
returned false, then obviously there is something wrong and it could be
caught before calling code sees it expecting it to be something else.Catching language-level error in application code is usually harder than
just handling it in user code. And if you are talking about distinction
between false/null and actual object, language level is the wrong level
to catch such things.
If you handle the error in runtime, you could have the check as well. If
you don't, the script breaks anyway, so it is not going to help you much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm going
to process only type X, and I make a requirement for others to pass only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in dynamic
interpreted languages.
Also, since from the client side there's no way to check if the function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.If I, or someone else decided to make a patch for this, and assuming it
worked exactly like I described, would it be accepted?I don't know... I personally don't see much use for it, but others may
disagree.
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide method-completion.
As nice a feature as that would be, I don't think it's worth modifying the
language syntax for. I agree that in a loosely typed language that sort of
thing needs to be checked by the application code anyway.
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
And Zend Studio does this for you already, if you use comment your code
correctly. I really don't see a good use for this, either.
Jeremy
-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Saturday, July 28, 2007 6:05 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
It would give you similar benefits to input type hinting, but
instead of
"Functions are now able to force parameters to be objects...", it
would
also read "Calling functions are now able to expect return types to
be
objects...". If a function was defined to return object Z, but
instead
returned false, then obviously there is something wrong and it could
be
caught before calling code sees it expecting it to be something
else.Catching language-level error in application code is usually harder
than
just handling it in user code. And if you are talking about
distinction
between false/null and actual object, language level is the wrong
level
to catch such things.
If you handle the error in runtime, you could have the check as well.
If
you don't, the script breaks anyway, so it is not going to help you
much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm
going
to process only type X, and I make a requirement for others to pass
only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type
X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in
dynamic
interpreted languages.
Also, since from the client side there's no way to check if the
function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.If I, or someone else decided to make a patch for this, and assuming
it
worked exactly like I described, would it be accepted?I don't know... I personally don't see much use for it, but others may
disagree.
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide
method-completion.
As nice a feature as that would be, I don't think it's worth modifying
the
language syntax for. I agree that in a loosely typed language that sort
of
thing needs to be checked by the application code anyway.
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the
possession
of every one, and the receiver cannot dispossess himself of it." --
Thomas
Jefferson
On one hand I agree, since PHP is so loosely typed. But it's hard to make
the argument that type-hinting return values is pointless, since PHP allows
(class) type-hinting with parameter values. I personally think type-hinting
is very nice, and not for the purposes of IDEs.
For example:
class Test {
function blah(mysqli $db) {
}
}
This validates at the language level the value passed is an instance of
mysqli. That is much more handy than doing this each time:
class Test {
function blah($db) {
if ($db instanceof mysqli)
.....
}
}
If one of the best selling points of PHP is its typeless environment, then
why make any of these available? It appears that we are moving more and
more towards what PHP was meant not to be. Of course, that is part of
evolution and adaptation; adapting to user demands.
I think it would personally be nice if type-hinting was available for
functions/methods and not variables (at this point).
-----Original Message-----
From: Jeremy Privett [mailto:jeremy@peak8solutions.com]
Sent: Saturday, July 28, 2007 7:21 PM
To: Larry Garfield; internals@lists.php.net
Subject: RE: [PHP-DEV] Re: Type-hinted return values in PHP5?
And Zend Studio does this for you already, if you use comment your code
correctly. I really don't see a good use for this, either.
Jeremy
-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com]
Sent: Saturday, July 28, 2007 6:05 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
It would give you similar benefits to input type hinting, but
instead of
"Functions are now able to force parameters to be objects...", it
would
also read "Calling functions are now able to expect return types to
be
objects...". If a function was defined to return object Z, but
instead
returned false, then obviously there is something wrong and it could
be
caught before calling code sees it expecting it to be something
else.Catching language-level error in application code is usually harder
than
just handling it in user code. And if you are talking about
distinction
between false/null and actual object, language level is the wrong
level
to catch such things.
If you handle the error in runtime, you could have the check as well.
If
you don't, the script breaks anyway, so it is not going to help you
much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm
going
to process only type X, and I make a requirement for others to pass
only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type
X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in
dynamic
interpreted languages.
Also, since from the client side there's no way to check if the
function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.If I, or someone else decided to make a patch for this, and assuming
it
worked exactly like I described, would it be accepted?I don't know... I personally don't see much use for it, but others may
disagree.
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide
method-completion.
As nice a feature as that would be, I don't think it's worth modifying
the
language syntax for. I agree that in a loosely typed language that sort
of
thing needs to be checked by the application code anyway.
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the
possession
of every one, and the receiver cannot dispossess himself of it." --
Thomas
Jefferson
On one hand I agree, since PHP is so loosely typed. But it's hard to make
the argument that type-hinting return values is pointless, since PHP allows
(class) type-hinting with parameter values. I personally think type-hinting
is very nice, and not for the purposes of IDEs.
The difference is that typehinting works this way:
- I'm a library, I want to get type X for $foo
- I put typehint, so I didn't need to check if $foo is X
- If you pass not X to $foo, my code is going to tell you that you
can't do that
And return type works like that:
- I'm a library writer that says foo() returns X
- I have to use for it, since I don't use foo()
- You're client, so you read the docs and see foo() returns X
- You write code which supposes foo() always returns X
- I decide these return types are more trouble than they are worth, and
make foo() return false on error, removing return type. - Your code has no way to check I did that, so it's broken now.
Basically, it sums up to documentation - if documentation isn't right
(or if it changed and you didn't follow) your code is going to break and
you have no way to prevent it. That's what you have now with @return -
why add language construct?
If one of the best selling points of PHP is its typeless environment, then
why make any of these available? It appears that we are moving more and
If it was up to me, I'd probably not bother adding input typehints
either :) But as I said above, input typehints are significantly
different from return types.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I see your point, but maybe I didn't explain myself well enough.
Take the example of an interface. Interfaces aren't directly accessible
(callable), they don't have any functional code in them. So why have them?
What is the single best advantage of an interface, especially in a very
large organization? It ensures consistency.
Take PDO for instance. They are a perfect candidate for interfaces. The
actual implementation of the close() method will differ based on the RDBMS,
but functionally, to the end-developer, they are the same. It closes the
database connection. Once a class implements an interface, and the
end-developer knows this, they don't have to worry about the name of the
method that closes the connection. Also, if the lead architect decides that
there must be a method called foo() in each of the given libs, he/she needs
only to enforce this through the interface, which is implemented by each
class! This can also assist in debugging.
I understand that there's a real difference between type-hinting return
values and parameters, but reverting back to the interface practice, why not
depend on the developer to add a new form of documentation to "promise" to
implement certain methods?
Will
-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: Sunday, July 29, 2007 3:07 AM
To: Will Fitch
Cc: 'Jeremy Privett'; 'Larry Garfield'; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
On one hand I agree, since PHP is so loosely typed. But it's hard to make
the argument that type-hinting return values is pointless, since PHP
allows
(class) type-hinting with parameter values. I personally think
type-hinting
is very nice, and not for the purposes of IDEs.
The difference is that typehinting works this way:
- I'm a library, I want to get type X for $foo
- I put typehint, so I didn't need to check if $foo is X
- If you pass not X to $foo, my code is going to tell you that you
can't do that
And return type works like that:
- I'm a library writer that says foo() returns X
- I have to use for it, since I don't use foo()
- You're client, so you read the docs and see foo() returns X
- You write code which supposes foo() always returns X
- I decide these return types are more trouble than they are worth, and
make foo() return false on error, removing return type. - Your code has no way to check I did that, so it's broken now.
Basically, it sums up to documentation - if documentation isn't right
(or if it changed and you didn't follow) your code is going to break and
you have no way to prevent it. That's what you have now with @return -
why add language construct?
If one of the best selling points of PHP is its typeless environment, then
why make any of these available? It appears that we are moving more and
If it was up to me, I'd probably not bother adding input typehints
either :) But as I said above, input typehints are significantly
different from return types.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide method-completion.
PHPDoc does that with @return tag.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
I think the only serious advantage I could see would be to allow
context-assistance IDEs more data, so they could provide
method-completion.PHPDoc does that with @return tag.
True but there will be times when the documentation is wrong[1] or when
the function returns something that it shouldn't.
Again, this really has little to do with IDEs. It is aimed improving the
interface language construct.
Stanislav Malyshev wrote:
It would give you similar benefits to input type hinting, but instead
of "Functions are now able to force parameters to be objects...", it
would also read "Calling functions are now able to expect return types
to be objects...". If a function was defined to return object Z, but
instead returned false, then obviously there is something wrong and it
could be caught before calling code sees it expecting it to be
something else.Catching language-level error in application code is usually harder than
just handling it in user code. And if you are talking about distinction
between false/null and actual object, language level is the wrong level
to catch such things.
If you handle the error in runtime, you could have the check as well. If
you don't, the script breaks anyway, so it is not going to help you much.
Even more, the return value is the product of the module code, while
input values are product of the outside code. So when you say "I'm going
to process only type X, and I make a requirement for others to pass only
X to me", it makes for me more sense than saying "I'm going to return
only type X so I'm making restriction for myself to return only type X".
The latter is more like declaring variable types, which have its
functions in compiled languages but usually is not happening in dynamic
interpreted languages.
Also, since from the client side there's no way to check if the function
you are calling actually does have the return type restriction, it's
quite hard to program basing on that from the client side. So you
actually check it in one place (library) and use it in entirely
different place (client) which is usually bad idea since the client
becomes too reliant on internal details of the library.If I, or someone else decided to make a patch for this, and assuming
it worked exactly like I described, would it be accepted?I don't know... I personally don't see much use for it, but others may
disagree.
That is true, there is absolutely no reason to say "I'm going to return
only type X so I'm making restriction for myself to return only type X".
However, this feature is geared towards interfaces, so that statement
becomes "Any interface that implements me must provide a method X that
takes Y as input and must return Z".