Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 2011-12-22, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really
doesn't want to accept type-juggled arguments, then it is easy
enough to do a strict type check in the function itself. This puts
the effort in the correct place and doesn't encourage this type of
coding.
Putting such code into the correct place does not change the
problem that you and Stas describe
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all
the correct places ...
I am not advocating type hints for scalars, I am just saying that
this argument is not really a good one against it.
But people don't really write code like this in PHP.
Um, I do. Often.
The first half of the security mantra is filter input. This also
applies to APIs -- you need to ensure you have input you can actually
work with. While I might not use the is_int() that Sebastian provided
above, I might do the following:
if (!is_numeric($age)) {
throw new InvalidArgumentException('Did not receive number');
}
if ((int) $age != $age) {
throw new InvalidArgumentException('Did not receive integer');
}
$age = (int) $age;
Why? Again, because I need to trust I have a value that I can work with.
Throwing an exception as soon as I know I can't work with the value is
easier to debug than having another function or operation raise an error
later -- these are often much harder to debug, as the source of the
input may be several steps removed by that point.
This is especially important for library and framework authors, as we
need to make the code robust for numerous use cases, most of which will
be beyond our immediate control. This makes debugging easier for end
users, and also makes documentation simpler.
Which is also why it makes very little sense to add strong typing of
scalars. Why would anyone want to add a feature that lets them do
something they would never do?
Despite the example I have above which I personally don't want strong
scalar type hinting. I _do_ favor the idea of casting hints, though --
simply because they would simplify my work tremendously, while still
giving me the benefits I have if I test my input manually.
The above code is much more likely to do an is_numeric() check and/or a
hard typecast to an int. But throwing an exception when it receives 21
instead of 21 just isn't something people tend to do.
I honestly don't think that was the point of Sebastian's example -- the
point was that instead of this:
function age_check(int $age)
{
// use the $age value with the knowledge that it's sane
}
we're forced to instead do manual checks within the function body
itself, which is repetitive, introduces new vectors for errors, and
potentially degrades performance. Additionally, it introduces a cost in
development -- additional tests and code need to be written.
snip
The only way I see something like this ever happening in PHP is if we
came up with an intelligent approach that actually was type *hinting*
and not strong typing. As in:
function ((int)$age) {
return ($age 21) ?: false;
}
that would gracefully handle interchangeable types. But it gets tricky
once we start thinking about non-numeric strings being passed in there.
Agreed on all accounts here. However, if it can be done, I think it
would be a huge boon to developers.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Scalars will not be supported as type hints. There was talk of a scalar token added for validation in that category, but it does NOT need to be supported for return type hinting to be included. Return type hints are following the same logic as parameter type hints and should be considered in that category. On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote: I think annotations is a completely different topic to be discussed separately. First the type hinting for variables and return values has to be supported by the language, including hinting for primitive types. If and when this is done, then, if annotations are supported natively, maybe these 2 can be combined. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] Sent: Tuesday, December 27, 2011 11:12 AM To: PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Also, the RFC will be changing tonight/tomorrow'ish to take procedures (functions) into account as well. I know there are many who want to address the additional types to hint (e.g. scalar keyword), but I would like to focus discussion of the RFC to its current state - which is to match the state of parameter type hints. On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote: I think annotations is a completely different topic to be discussed separately. First the type hinting for variables and return values has to be supported by the language, including hinting for primitive types. If and when this is done, then, if annotations are supported natively, maybe these 2 can be combined. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] Sent: Tuesday, December 27, 2011 11:12 AM To: PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch will.fi...@gmail.com wrote:
In the interest of providing options for an ability to mark a method as
returning null, I have added a new patch here:
http://www.willfitch.com/php/nullable.patch
This includes a new token T_NULLABLE. Here are a few examples:
// This is allowed
private nullable ArrayIterator getIterator()
{
return null;
}
// This throws an E_RECOVERABLE_ERROR
private ArrayIterator getIterator()
{
return null;
}
The token/identifier can certainly change, but I want to provide the most
options for the best solution.
This looks fine to me, looks more php like then the C# examples.
On Dec 23, 2011, at 6:31 PM, André Rømcke wrote:
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to
return null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public NullableSystem.DateTime Time { get; set; }
IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
For the record; This was not ment as an argument against scalar, and
similar type hints ( object, callable.. ) .
It was an argument against hinting about something and getting
something completely different (null).
Happy xmas!
Re: [PHP-DEV] Return Type Hinting for Methods RFC
The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 18:59, Will Fitch will.fi...@gmail.com wrote:
Would you prefer to allow methods with type hinted return values to return
null at will, or add a marker noting that it *may* return null?
My preference would be to have a marker, and when null is not allowed, if the
function tries to return it (or fails to return anything at all), then an error
is raised or exception thrown. This behavior would be great for those cases
where you're trying to protect against situations that theoretically should be
impossible, much like the role of assertions. The marker then would handle
those situations where you want to explicitly allow null return values based on
routine inputs.
A common problem with PHP is that you just don't know what a function might do
if you don't look over its code or it's docs. The marker makes one part of its
behavior explicit, thus abbreviating the guessing game. (Not to mention when
the docs themselves errantly fail to mention that a function can return types
other than the obvious)
In fitting with the PHP way, perhaps it would make sense that the marker
indicates not just that null may be returned, but that any type may be
returned. This would allow, say, returning false or -1 instead of null. Or
maybe it's better just to allow indication of multiple types and have the
marker be for just for null.
public ArrayIterator getIterator()
I would really, really prefer to always have the 'function' keyword be present.
It offers something to scan for when quickly reviewing code, it makes it easier
to do search-and-replace operations on functions, and it allows text editors
that don't have the full-blown lexical analyzer of an IDE to still be able to
pick out all the functions and offer the user an easy navigation feature.
I do, however, quite like the idea of putting the return type at the end of the
function declaration. I've always disliked the way C and its derivatives stick
the return type at the beginning (along with an ever-increasing list of other
keywords), since it makes it harder to quickly scan the code by forcing a more
thorough mental parsing instead of just letting you snap your eye to a known
position. As for an operator suggestion, one precedent I can think of is from
Pascal, which uses a colon:
function GetName(): string
This puts the result type at the end where you always know right where to look
for it without mental parsing, and it reads naturally in that the effect (the
result) is listed after the cause (the function). And, at least for English
writers, the colon's purpose is intuitive because of its use in English
grammar. Finally, PHP doesn't already use the single colon for anything that I
can think of off-hand.
I'd also like to comment on the use of type checking in PHP. I completely agree
that having more broad checking available in the language would be a great
thing. However, I also understand the criticisms against it. What if, instead
of specifying strict scalar types, like int, one could specify a type class
(not in the OOP sense)? The concept has already been alluded to, but I don't
think anyone has run with the idea yet. I'm thinking here of things like PHP's
filter functions or the character classes in regular expressions. So you might
specify a type of 'digits', which would allow anything that consists only of
the numbers 0-9, or which could losslessly (by which I mean reversible to the
same starting value) be cast to such a beast, equivalent to this monstrosity
that I frequently find myself using:
if (!\ctype_digit((string)$parameterValue) {
...
}
(I think it was Stas that mentioned using is_numeric() for things like this,
but I find that function virtually useless since it unconditionally allows
oddities like hex values that you typically don't want to allow. The other
alternative, is_int(), forces the very type of strict checking--and thus,
calling-side casting--that we all wish to avoid.)
Allowing specifications of types that are more flexible than the base scalars
would enable type checking but retain the advantages that a dynamic language
offers.
That said, I suspect that no one is talking about this option because it's been
discussed a million times in the past and deemed a bad and/or unworkable
solution for whatever reasons. :-)
--
Bob Williams
Notice: This communication, including attachments, may contain information that
is confidential. It constitutes non-public information intended to be conveyed
only to the designated recipient(s). If the reader or recipient of this
communication is not the intended recipient, an employee or agent of the
intended recipient who is responsible for delivering it to the intended
recipient, or if you believe that you have received this communication in
error, please notify the sender immediately by return e-mail and promptly
delete this e-mail, including attachments without reading or saving them in any
manner. The unauthorized
RE: [PHP-DEV] Return Type Hinting for Methods RFC
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to return
null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
IMO allowing null should be the default unless specifically disallowed.
I far prefer the addition/use of a keyword (notnull or null) to disallow
(or allow) as opposed to random symbol abuse (potential incompatibilities
notwithstanding).
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Ángel González [mailto:keis...@gmail.com]
Sent: Thursday, December 22, 2011 7:45 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
That syntax is pretty readable, would there be alternatives such as:
function foo() returns Class3, array or null {
}
-Original Message-
From: Dmitri Snytkine [mailto:dsnytk...@ultralogistics.com]
Sent: Friday, December 23, 2011 7:48 AM
To: 'Ángel González'; 'PHP Developers Mailing List'
Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Ángel González [mailto:keis...@gmail.com]
Sent: Thursday, December 22, 2011 7:45 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel
there should be some token there before the class name, though I'm
unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Im personally not a fan of declaring multiple return values. This
defeats the purpose of being more strict. If your method may return
different values outside of the declared type, then using the standard
function keyword would signify mixed.
There's still the matter of whether allowing null to be returned,
regardless of the situation, or using another token to identify that
it could return null. I'd like to know what others think. I see Stas'
argument that you'll still have to check, but I'm not so sure that is
such a bad thing.
Sent from my iPad
On Dec 23, 2011, at 3:07 PM, Clint M Priest cpri...@zerocue.com wrote:
That syntax is pretty readable, would there be alternatives such as:
function foo() returns Class3, array or null {
}
-Original Message-
From: Dmitri Snytkine [mailto:dsnytk...@ultralogistics.com]
Sent: Friday, December 23, 2011 7:48 AM
To: 'Ángel González'; 'PHP Developers Mailing List'
Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Ángel González [mailto:keis...@gmail.com]
Sent: Thursday, December 22, 2011 7:45 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel
there should be some token there before the class name, though I'm
unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. Many have expressed this same concern. I'm going to update the patch and RFC to reflect this. If we decide to add a marker/token to indicate allowing null, we will decide after discussing this change. Baby steps 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to
return null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public NullableSystem.DateTime Time { get; set; }
IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Sent from my iPhone
On Dec 23, 2011, at 6:32 PM, André Rømcke a...@ez.no wrote:
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to
return null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public NullableSystem.DateTime Time { get; set; }
If it is decided that we continue down the road of limiting nullable
returns, and want to add an indicator, what about something like this:
public nullable ArrayIterator getIterator()
If the nullable token isn't declared, it can't return null.
IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
Re: [PHP-DEV] Return Type Hinting for Methods RFC
In the interest of providing options for an ability to mark a method as
returning null, I have added a new patch here:
http://www.willfitch.com/php/nullable.patch
This includes a new token T_NULLABLE. Here are a few examples:
// This is allowed
private nullable ArrayIterator getIterator()
{
return null;
}
// This throws an E_RECOVERABLE_ERROR
private ArrayIterator getIterator()
{
return null;
}
The token/identifier can certainly change, but I want to provide the most
options for the best solution.
On Dec 23, 2011, at 6:31 PM, André Rømcke wrote:
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to return
null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
I hate the syntax in the second example (using ?).
It looks strange, but easy to get used to. Two examples from C#:
public decimal? Grade { get; set; }
public NullableSystem.DateTime Time { get; set; }
IMO allowing null should be the default unless specifically disallowed.
I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.
RE: [PHP-DEV] Return Type Hinting for Methods RFC
The return type hinting is probably the biggest thing happening in php in a long time. Is this too good to be true? With return type hinting I can see a huge improvenets in php IDEs in spotting errors. Also it will be much easier to auto generate wsdl files when return types are known to a compiler. These are just to name a couple of important benefits that can come out of it. What I don't see is any discussion of being able to declare the type of variable, you now, like in Java. ie: private \ArrayObject $customers; Also, is there an implicit void return type? I hope that declaring types of variables will be added too because without it, this feature is not all that useful. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Will Fitch [mailto:will.fi...@gmail.com] Sent: Wednesday, December 21, 2011 5:29 PM To: Pierre Joye Cc: Nikita Popov; PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC Hi Pierre and Nikita, I have added callable to the patch and updated the RFC entry to reflect the changes. Please verify and let me know if you have any issues. On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote: hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
2011/12/22 Dmitri Snytkine dsnytk...@ultralogistics.com The return type hinting is probably the biggest thing happening in php in a long time. Is this too good to be true? With return type hinting I can see a huge improvenets in php IDEs in spotting errors. Also it will be much easier to auto generate wsdl files when return types are known to a compiler. These are just to name a couple of important benefits that can come out of it. What I don't see is any discussion of being able to declare the type of variable, you now, like in Java. ie: private \ArrayObject $customers; Once more Why is PHP not Java? Also, is there an implicit void return type? I hope that declaring types of variables will be added too because without it, this feature is not all that useful. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Will Fitch [mailto:will.fi...@gmail.com] Sent: Wednesday, December 21, 2011 5:29 PM To: Pierre Joye Cc: Nikita Popov; PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC Hi Pierre and Nikita, I have added callable to the patch and updated the RFC entry to reflect the changes. Please verify and let me know if you have any issues. On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote: hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 09:09:40AM -0500, Dmitri Snytkine wrote: The return type hinting is probably the biggest thing happening in php in a long time. Is this too good to be true? With return type hinting I can see a huge improvenets in php IDEs in spotting errors. Also it will be much easier to auto generate wsdl files when return types are known to a compiler. These are just to name a couple of important benefits that can come out of it. What I don't see is any discussion of being able to declare the type of variable, you now, like in Java. ie: private \ArrayObject $customers; That looks like a namespace - I don't like that syntax. Also, is there an implicit void return type? I hope that declaring types of variables will be added too because without it, this feature is not all that useful. If - we do allow variable declaration to specify a type, can we also have a syntax that simply says ''this variable is declared but I am not saying what type it is''. Ie the variable can take any type - just as now. Why ? One thing that I would really like to see in PHP is the ability to force variables in a module to be declared -- AKA perl's 'use strict'. Have the compiler complain if it sees a variable that has not been declared. In a large program the occasional typeo on variable names does happen, catching them with 'use strict' is great! I have proposed this before and people did not like it. Here is to hopeing for a different sentiment. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 9:09 AM, Dmitri Snytkine wrote: The return type hinting is probably the biggest thing happening in php in a long time. Is this too good to be true? Hopefully not. We will see when the voting commences. :) With return type hinting I can see a huge improvenets in php IDEs in spotting errors. Also it will be much easier to auto generate wsdl files when return types are known to a compiler. These are just to name a couple of important benefits that can come out of it. What I don't see is any discussion of being able to declare the type of variable, you now, like in Java. ie: private \ArrayObject $customers; Type hinting is relatively new to PHP, so we need to take careful steps in moving forward. With the introduction of parameter type hinting 5.0, and return type hinting following its lead, we will set ourselves up for a good base for a type hinting API and structure. That said, PHP is not Java, and type hinting in PHP is very different. It is, in fact, type *hinting*. This is a runtime feature. Only interface validation is verified at compile time, so we have to consider performance vs. feature in these cases. Also, is there an implicit void return type? The following types are allowed for both parameters and method returns: - Callable - Object (class name) - Array By not declaring a type hint with a parameter, it is considered mixed. With method returns, simply using the keyword function as you have been will signify mixed as well. I hope that declaring types of variables will be added too because without it, this feature is not all that useful. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Will Fitch [mailto:will.fi...@gmail.com] Sent: Wednesday, December 21, 2011 5:29 PM To: Pierre Joye Cc: Nikita Popov; PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC Hi Pierre and Nikita, I have added callable to the patch and updated the RFC entry to reflect the changes. Please verify and let me know if you have any issues. On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote: hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote: private \ArrayObject $customers; Once more Why is PHP not Java? That comment confuses matters. People use PHP for all sorts of reasons, the desire to tighten up in some places, on some occasions, should not be treated with derision. Tighter declarations, or any declarations at all, would not be mandatory. It would be something that some projects might want to do. It would be nice if this could be done on a module but module basis ... eg the implementors of a class library might want to be really strict while allowing the class users to not be strict. Just because Java has a feature that you appear to not like, does not mean that others might not want it in some circumstances. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
I never said to make it mandatory, only to make it available. Just like the type hinting of function call is optional but not mandatory, which is a big advantage over Java in my opinion. After all, if you make return type hinting mandatory, it would break 100% of all existing php scripts. To clarify I am asking to make type hinting for variable declaration an available option. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Alain Williams [mailto:a...@phcomp.co.uk] Sent: Thursday, December 22, 2011 9:52 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote: private \ArrayObject $customers; Once more Why is PHP not Java? That comment confuses matters. People use PHP for all sorts of reasons, the desire to tighten up in some places, on some occasions, should not be treated with derision. Tighter declarations, or any declarations at all, would not be mandatory. It would be something that some projects might want to do. It would be nice if this could be done on a module but module basis ... eg the implementors of a class library might want to be really strict while allowing the class users to not be strict. Just because Java has a feature that you appear to not like, does not mean that others might not want it in some circumstances. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Could we maybe keep this discussion contained to return value type hints please? Optional variable type hinting is a completely different topic that would require a separate RFC and implementation. If you are interested in this you can propose a RFC for this. Nikita On Thu, Dec 22, 2011 at 3:59 PM, Dmitri Snytkine dsnytk...@ultralogistics.com wrote: I never said to make it mandatory, only to make it available. Just like the type hinting of function call is optional but not mandatory, which is a big advantage over Java in my opinion. After all, if you make return type hinting mandatory, it would break 100% of all existing php scripts. To clarify I am asking to make type hinting for variable declaration an available option. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Alain Williams [mailto:a...@phcomp.co.uk] Sent: Thursday, December 22, 2011 9:52 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote: private \ArrayObject $customers; Once more Why is PHP not Java? That comment confuses matters. People use PHP for all sorts of reasons, the desire to tighten up in some places, on some occasions, should not be treated with derision. Tighter declarations, or any declarations at all, would not be mandatory. It would be something that some projects might want to do. It would be nice if this could be done on a module but module basis ... eg the implementors of a class library might want to be really strict while allowing the class users to not be strict. Just because Java has a feature that you appear to not like, does not mean that others might not want it in some circumstances. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
On Thu, Dec 22, 2011 at 2:59 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
I never said to make it mandatory, only to make it available. Just like the
type hinting of function call is optional but not mandatory, which is a big
advantage over Java in my opinion.
After all, if you make return type hinting mandatory, it would break 100%
of
all existing php scripts.
To clarify I am asking to make type hinting for variable declaration an
available option.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject $customers;
Once more Why is PHP not Java?
That comment confuses matters. People use PHP for all sorts of reasons, the
desire to tighten up in some places, on some occasions, should not be
treated
with derision.
Tighter declarations, or any declarations at all, would not be mandatory.
It
would
be something that some projects might want to do. It would be nice if this
could be
done on a module but module basis ... eg the implementors of a class
library
might
want to be really strict while allowing the class users to not be strict.
Just because Java has a feature that you appear to not like, does not mean
that
others might not want it in some circumstances.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
I think the return type hinting really depends on variable type hinting.
A simple example whould bea typical getter function
public function \Customer getCustomer(){
return $this-customer;
}
If the $customer instance variable is not declared with the type Customer
then first of all IDE will not be able to spot an error, second compiler may
have a slighly harder time of detecting a mismatch.
I really believe that variable type hinting should be worked on at the same
time or even before the type hinting for returns.
But it's not up to me of cause, just adding my thoughts to the discussion of
this topic. I think this is a very important topic by the way.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Nikita Popov [mailto:nikita@googlemail.com]
Sent: Thursday, December 22, 2011 10:02 AM
To: Dmitri Snytkine
Cc: Alain Williams; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Could we maybe keep this discussion contained to return value type
hints please? Optional variable type hinting is a completely different
topic that would require a separate RFC and implementation. If you are
interested in this you can propose a RFC for this.
Nikita
On Thu, Dec 22, 2011 at 3:59 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
I never said to make it mandatory, only to make it available. Just like
the
type hinting of function call is optional but not mandatory, which is a
big
advantage over Java in my opinion.
After all, if you make return type hinting mandatory, it would break 100%
of
all existing php scripts.
To clarify I am asking to make type hinting for variable declaration an
available option.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject $customers;
Once more Why is PHP not Java?
That comment confuses matters. People use PHP for all sorts of reasons,
the
desire to tighten up in some places, on some occasions, should not be
treated
with derision.
Tighter declarations, or any declarations at all, would not be mandatory.
It
would
be something that some projects might want to do. It would be nice if this
could be
done on a module but module basis ... eg the implementors of a class
library
might
want to be really strict while allowing the class users to not be strict.
Just because Java has a feature that you appear to not like, does not mean
that
others might not want it in some circumstances.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 09:59:16AM -0500, Dmitri Snytkine wrote: I never said to make it mandatory, only to make it available. Just like the type hinting of function call is optional but not mandatory, which is a big advantage over Java in my opinion. After all, if you make return type hinting mandatory, it would break 100% of all existing php scripts. Agreed. I did not make myself clear enough: It should be optional/available but with an option to make it mandatory for a module -- on a module by module basis so that it did not affect code outside of the module. To clarify I am asking to make type hinting for variable declaration an available option. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
scalar type hinting was rejected in the past multiple times.
I think that expanding this RFC (against the wish of the original author of
the RFC) would be a sure way to guarantee the same result for this RFC as
well..
On Thu, Dec 22, 2011 at 4:08 PM, Keloran ava...@gmail.com wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
On Thu, Dec 22, 2011 at 2:59 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
I never said to make it mandatory, only to make it available. Just like
the
type hinting of function call is optional but not mandatory, which is a
big
advantage over Java in my opinion.
After all, if you make return type hinting mandatory, it would break 100%
of
all existing php scripts.
To clarify I am asking to make type hinting for variable declaration an
available option.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject $customers;
Once more Why is PHP not Java?
That comment confuses matters. People use PHP for all sorts of reasons,
the
desire to tighten up in some places, on some occasions, should not be
treated
with derision.
Tighter declarations, or any declarations at all, would not be mandatory.
It
would
be something that some projects might want to do. It would be nice if
this
could be
done on a module but module basis ... eg the implementors of a class
library
might
want to be really strict while allowing the class users to not be strict.
Just because Java has a feature that you appear to not like, does not
mean
that
others might not want it in some circumstances.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Return Type Hinting for Methods RFC
public function \Customer getCustomer(){
return $this-customer;
}
If the $customer instance variable is not declared with the type Customer
then first of all IDE will not be able to spot an error, second compiler may
have a slighly harder time of detecting a mismatch.
The compiler does not even try to detect a mismatch; type hinting is
taken into account at run-time only. So whenever this function executes,
if it tries to return a value that is not a \Customer, a run-time error
will be reported.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote:
I think the return type hinting really depends on variable type hinting.
A simple example whould bea typical getter function
public function \Customer getCustomer(){
return $this-customer;
}
The actual syntax would be:
public \Customer getCustomer()
If the $customer instance variable is not declared with the type Customer
then first of all IDE will not be able to spot an error, second compiler may
have a slighly harder time of detecting a mismatch.
This isn't a compile time feature. The validation happens at runtime. Many
IDEs actually use PHP executables to detect syntax errors only. In terms of
code flow, they'll still need to rely on Doc comments and lexical analysis.
I really believe that variable type hinting should be worked on at the same
time or even before the type hinting for returns.
But it's not up to me of cause, just adding my thoughts to the discussion of
this topic. I think this is a very important topic by the way.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Nikita Popov [mailto:nikita@googlemail.com]
Sent: Thursday, December 22, 2011 10:02 AM
To: Dmitri Snytkine
Cc: Alain Williams; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Could we maybe keep this discussion contained to return value type
hints please? Optional variable type hinting is a completely different
topic that would require a separate RFC and implementation. If you are
interested in this you can propose a RFC for this.
Nikita
On Thu, Dec 22, 2011 at 3:59 PM, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
I never said to make it mandatory, only to make it available. Just like
the
type hinting of function call is optional but not mandatory, which is a
big
advantage over Java in my opinion.
After all, if you make return type hinting mandatory, it would break 100%
of
all existing php scripts.
To clarify I am asking to make type hinting for variable declaration an
available option.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject $customers;
Once more Why is PHP not Java?
That comment confuses matters. People use PHP for all sorts of reasons,
the
desire to tighten up in some places, on some occasions, should not be
treated
with derision.
Tighter declarations, or any declarations at all, would not be mandatory.
It
would
be something that some projects might want to do. It would be nice if this
could be
done on a module but module basis ... eg the implementors of a class
library
might
want to be really strict while allowing the class users to not be strict.
Just because Java has a feature that you appear to not like, does not mean
that
others might not want it in some circumstances.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 10:18 AM, Oleg Oshmyan wrote:
public function \Customer getCustomer(){
return $this-customer;
}
If the $customer instance variable is not declared with the type Customer
then first of all IDE will not be able to spot an error, second compiler may
have a slighly harder time of detecting a mismatch.
The compiler does not even try to detect a mismatch; type hinting is
taken into account at run-time only. So whenever this function executes,
if it tries to return a value that is not a \Customer, a run-time error
will be reported.
The only exception is implementing an interface that defines a returned type
hint. This is detected at compile time but only to the point that the
implemented method prototype is the same type hint. If it is not, an
E_COMPILE_ERROR is raised. The runtime error raised is an E_RECOVERABLE_ERROR.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! Could we maybe keep this discussion contained to return value type hints please? Optional variable type hinting is a completely different topic that would require a separate RFC and implementation. If you are interested in this you can propose a RFC for this. Actually, as I said many times in previous discussions on the topic, strict typing is useless (and, IMHO, even worse than that) if applied in small parts. If you have strict typing in return values, you'd have to have strict typing in variables, etc. - otherwise you'd have no way to protect yourself from hard-to-find runtime errors. And, actually, after that you'd have to make PHP compiled - since otherwise runtime errors will still be there. So in my opinion restricting discussion to return type strict typing is just deluding yourself. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! That said, PHP is not Java, and type hinting in PHP is very different. It is, in fact, type *hinting*. This is a runtime feature. Only interface validation is verified at compile time, so we have to consider performance vs. feature in these cases. Naming it hinting was probably the worst mistake in PHP documentation since safe mode. The word hinting implies it's just something non-mandatory, that can be used if needed, but ignored if not. While using typing is indeed not mandatory, once used, it *is* mandatory check that can not be ignored and produces fatal error in case of mismatch. The only difference is that in Java this error is detected in compile time, while in PHP it is a runtime failure, usually taking down the application in the middle of processing, without possibility of proper recovery. I'm not sure we're having the better deal here. Performance is irrelevant here, more or less, since typing checks won't take much time unless you have insanely deep class hierarchies (you have to compare object's class and probably his parents' to the prescribed type). Stability and maintainability of such code is an issue. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
I agree with Rasmus.
My opinion:
This isn't java, if you want a strongly typed language, there's plenty out
there, but we're not looking to make PHP more like Java and the rest, if it
was like Java then it wouldn't have been successful for the web as it
is/was. PHP is popular because of the way it was from the start, if php
_needed_ scalar typehints then it wouldn't have been as popular.
There is need for the existing Typehinting for class types so you don't
need to have is_a() function calls. This makes sense.
Scalars are VERY powerful in PHP, because of its loose typed nature. Having
a 'numeric' typehint makes sense, because it can be an int, float, or
string. Adding typehints like 'int' and 'float' will only piss people off,
and make PHP more difficult and less fluent to code in.
Lets not go there please..
Thanks,
Paul Dragoonis.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
Putting such code into the correct place does not change the problem
that you and Stas describe
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
I am not advocating type hints for scalars, I am just saying that this
argument is not really a good one against it.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi!
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
That's because you should be using is_numeric in this context ;) And
have an answer on the question what happens if it's not that does not
involve throwing exception that nobody is going to catch. Of course,
you can't design proper library in one line. The idea is that strict
typing doesn't make such design easier, since it does not lead to less work.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
I agree that Return type hinting needs to be aligned with parameter type
hinting. That's basically what I said in previous post, that without
parameter type the return type hinting is not very useful, it's like
half-baked
While web isn't typed, the php is not just for the web anymore, or is it?
Some databases expect typed input, else the data is not found.
For example passing string '1' instead of number 1 will not cause any errors
when searching MongoDB but you will not get the result you expect to get if
the value of key is integer 1
Strong typing just helps, adds sanity to your program. The fact that it can
be made optional and not required is a great benefit also.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Thursday, December 22, 2011 1:41 PM
To: Keloran
Cc: Dmitri Snytkine; Alain Williams; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime easy and throw recoverable fatal error that you can catch.
the well designed IDE can also catch error in your code if your parameters
and all returnes are typed, so that will also save you a lot of time.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Thursday, December 22, 2011 1:55 PM
To: Sebastian Bergmann
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi!
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
That's because you should be using is_numeric in this context ;) And
have an answer on the question what happens if it's not that does not
involve throwing exception that nobody is going to catch. Of course,
you can't design proper library in one line. The idea is that strict
typing doesn't make such design easier, since it does not lead to less work.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
Putting such code into the correct place does not change the problem
that you and Stas describe
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
I am not advocating type hints for scalars, I am just saying that this
argument is not really a good one against it.
But people don't really write code like this in PHP. Which is also why
it makes very little sense to add strong typing of scalars. Why would
anyone want to add a feature that lets them do something they would
never do?
The above code is much more likely to do an is_numeric() check and/or a
hard typecast to an int. But throwing an exception when it receives 21
instead of 21 just isn't something people tend to do.
And Dmitri, in the Mongo case you mentioned, parameters to Mongo need to
be json-wrapped, so you are going to have access functions doing this.
Why would you not want to typecast in the access function there as well
as opposed to throwing hard to catch exceptions going into the access
functions themselves?
The only way I see something like this ever happening in PHP is if we
came up with an intelligent approach that actually was type *hinting*
and not strong typing. As in:
function ((int)$age) {
return ($age 21) ?: false;
}
that would gracefully handle interchangeable types. But it gets tricky
once we start thinking about non-numeric strings being passed in there.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
Have you taken a look at the RFC and/or patch? This functionality is exactly
aligned with parameter type hinting. Only classes, arrays and callables are
allowed types. I agree 100% on scalars.
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
It absolutely isn't. I'm also against the class casting RFC which would, in
effect, do this very same thing.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi!
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime easy and throw recoverable fatal error that you can catch.
You can catch and do what? By that time you application has failed with
no chance to recover, since you can't go back to age_check call and say
oh, sorry, when I said '1' I actually meant integer 1, please accept
it! The only thing you can do is to output a nice error message, and
since this is nothing the user can correct, since it's not his problem
but a code bug, it'll be something like something went wrong, oops,
please go to another page of the site and hope it will be programmed
better than this one!. That's pretty much your options when using
strict typed function - unless you either have strict typing throughout
the whole code path(s) that lead to the age_check call or do an explicit
check with explicit failure handling each time you try to call it.
the well designed IDE can also catch error in your code if your parameters
and all returnes are typed, so that will also save you a lot of time.
I start to feel well designed IDE is a substitute for a compiler for
some. PHP is not a compiled language, however, at least not yet - and
since it's not, relying on mythical well designed IDE to perform the
function that compiler performs in static-typed compiled languages is,
IMHO, misguided.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 11:18 AM, Will Fitch wrote:
On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
Have you taken a look at the RFC and/or patch? This functionality is exactly
aligned with parameter type hinting. Only classes, arrays and callables are
allowed types. I agree 100% on scalars.
Yes, I know, but any talk about typing invariable brings the strong
typing scalars proponents out of the woodwork.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
Not sure what you mean by json wrapped.
In mongo you do $coll-find(array('age' = $age);
if $age is a string '21' your will not get any erros but neither will you
get any results.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Thursday, December 22, 2011 2:12 PM
To: Sebastian Bergmann
Cc: internals@lists.php.net; Dmitri Snytkine
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
Putting such code into the correct place does not change the problem
that you and Stas describe
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
I am not advocating type hints for scalars, I am just saying that this
argument is not really a good one against it.
But people don't really write code like this in PHP. Which is also why
it makes very little sense to add strong typing of scalars. Why would
anyone want to add a feature that lets them do something they would
never do?
The above code is much more likely to do an is_numeric() check and/or a
hard typecast to an int. But throwing an exception when it receives 21
instead of 21 just isn't something people tend to do.
And Dmitri, in the Mongo case you mentioned, parameters to Mongo need to
be json-wrapped, so you are going to have access functions doing this.
Why would you not want to typecast in the access function there as well
as opposed to throwing hard to catch exceptions going into the access
functions themselves?
The only way I see something like this ever happening in PHP is if we
came up with an intelligent approach that actually was type *hinting*
and not strong typing. As in:
function ((int)$age) {
return ($age 21) ?: false;
}
that would gracefully handle interchangeable types. But it gets tricky
once we start thinking about non-numeric strings being passed in there.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 1:50 PM, Paul Dragoonis wrote:
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
I agree with Rasmus.
My opinion:
This isn't java, if you want a strongly typed language, there's plenty out
there, but we're not looking to make PHP more like Java and the rest, if it
was like Java then it wouldn't have been successful for the web as it
is/was. PHP is popular because of the way it was from the start, if php
_needed_ scalar typehints then it wouldn't have been as popular.
There is need for the existing Typehinting for class types so you don't
need to have is_a() function calls. This makes sense.
Scalars are VERY powerful in PHP, because of its loose typed nature. Having
a 'numeric' typehint makes sense, because it can be an int, float, or
string. Adding typehints like 'int' and 'float' will only piss people off,
and make PHP more difficult and less fluent to code in.
Lets not go there please..
I agree. Let's not go there. I'd like to focus more on the actual RFC at
hand. It makes sense to discuss potentials and what if's, but type hinting
scalars has been shot down many times - the most important being that it would
destroy the loosely typed nature of scalars.
Thanks,
Paul Dragoonis.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 1:51 PM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
Putting such code into the correct place does not change the problem
that you and Stas describe
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct places ...
There are cases, such as the one you pointed out, that requires type casting.
We're just trying to point out a situation where, if scalars were allowed to be
typed, would produce code littered with type casts. Point taken though.
I am not advocating type hints for scalars, I am just saying that this
argument is not really a good one against it.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
What I mean is that you can catch recoverable fatal error in your error
handler and at least be notified of what happened. Yes, you cannot go back
in your script to corrent anything after that but you can show a detailed
error message and send error email to developer.
Just the same thing you can do when you hint class name for your input
parameter - it will generate catchable fatal error if object is not an
instance of expected class.
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Thursday, December 22, 2011 2:19 PM
To: Dmitri Snytkine
Cc: 'Sebastian Bergmann'; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi!
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime easy and throw recoverable fatal error that you can catch.
You can catch and do what? By that time you application has failed with
no chance to recover, since you can't go back to age_check call and say
oh, sorry, when I said '1' I actually meant integer 1, please accept
it! The only thing you can do is to output a nice error message, and
since this is nothing the user can correct, since it's not his problem
but a code bug, it'll be something like something went wrong, oops,
please go to another page of the site and hope it will be programmed
better than this one!. That's pretty much your options when using
strict typed function - unless you either have strict typing throughout
the whole code path(s) that lead to the age_check call or do an explicit
check with explicit failure handling each time you try to call it.
the well designed IDE can also catch error in your code if your parameters
and all returnes are typed, so that will also save you a lot of time.
I start to feel well designed IDE is a substitute for a compiler for
some. PHP is not a compiled language, however, at least not yet - and
since it's not, relying on mythical well designed IDE to perform the
function that compiler performs in static-typed compiled languages is,
IMHO, misguided.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! What I mean is that you can catch recoverable fatal error in your error handler and at least be notified of what happened. Yes, you cannot go back in your script to corrent anything after that but you can show a detailed error message and send error email to developer. Just the same thing you can do when you hint class name for your input parameter - it will generate catchable fatal error if object is not an instance of expected class. Exactly, strict typing has same flaws everywhere, and this is exactly the reason it's not a solution for the problem it is presented to be - it does not make your code more robust or fail less or saves you effort on development - it just produces different error messages. While the case of wrong object type is rare enough to warrant application failure in case it happens - the case for scalar types is completely different. It was discussed many times on the list. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 11:20 AM, Dmitri Snytkine wrote:
Not sure what you mean by json wrapped.
In mongo you do $coll-find(array('age' = $age);
if $age is a string '21' your will not get any erros but neither will you
get any results.
It is json underneath, but in your find() example, obviously the right
approach here is to do:
$coll-find(array('age' = (int)$age);
How is that hard?
You wouldn't use a strong int type in the find() function prototype here
at all since by definition the find() function needs to take all sorts
of types. This is why I mentioned access functions related to Mongo. You
might write something like:
function age_lookup($age) {
return $coll-find(array('age' = (int)$age);
}
but again here, doing a strong type check on the parameter isn't making
your life easier. It simply pushes the responsibility to the caller and
introduces a tricky unrecoverable error that will drive you crazy unless
you have 100% regression test coverage (which is kind of impossible
since the number of inputs is infinite) or great static analysis tools.
PHP is not a compiled language, so you end up not catching these until
runtime which is obviously sub-optimal.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
How is that hard?
function age_lookup($age) {
return $coll-find(array('age' = (int)$age);
}
but again here, doing a strong type check on the parameter isn't making your
life easier. It simply pushes the responsibility to the caller and introduces
a tricky unrecoverable error that will drive you crazy unless you have 100%
regression test coverage (which is kind of impossible since the number of
inputs is infinite) or great static analysis tools.
PHP is not a compiled language, so you end up not catching these until runtime
which is obviously sub-optimal.
-Rasmus
This will silently fail in a very bad way when the caller accidentally passes
in (for example) an array. With a scalar type hint it would die loudly (quickly
alerting the developer to the problem) and code analysis tools (even just a
decent IDE) could highlight the error even before it is executed.
The point here is that the caller is already responsible to make sure it passes
the right value, but the language currently offers no means of documenting
that, and no easy way to ensure it.
There's obviously a question about how much juggling to allow with a scalar
type hint. IMO the obvious stuff (36 to 36, etc.) is perfect, but passing
foobar or array(1,2,3) to an int should throw an error.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 11:49 AM, John Crenshaw wrote:
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
How is that hard?
function age_lookup($age) {
return $coll-find(array('age' = (int)$age);
}
but again here, doing a strong type check on the parameter isn't making your
life easier. It simply pushes the responsibility to the caller and
introduces a tricky unrecoverable error that will drive you crazy unless you
have 100% regression test coverage (which is kind of impossible since the
number of inputs is infinite) or great static analysis tools.
PHP is not a compiled language, so you end up not catching these until
runtime which is obviously sub-optimal.
-Rasmus
This will silently fail in a very bad way when the caller accidentally passes
in (for example) an array. With a scalar type hint it would die loudly
(quickly alerting the developer to the problem) and code analysis tools (even
just a decent IDE) could highlight the error even before it is executed.
That's an argument for scalar as the type hint, not for int vs.
string. I'm not against scalar as a type hint. I am against hints
that prevent interchangeable types from being passed. scalar, array,
object, callable are fine.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Stas, it's not a solution for the problem it is presented to be - it does not make your code more robust or fail less or saves you effort on development I'm going to have to disagree with you there. Type hinting DOES save me a LOT of effort in development. I can stop worrying about checking to make sure the parameter that I got is what I want it to be, and just use it. The runtime will check and enforce that for me. When using things like Dependency Injection, it's crucial to have type-hints, otherwise you need to do the enforcement yourself (which a lot of people don't do). Sure, it does introduce its own issues with throwing exceptions (I convert all ~notice errors into exceptions by default), but at least I know **why** the error happened. If the parameter is not correct, it will tell me what was passed vs what was required. Without type hinting, I would be in a situation where I would be responsible for that error (if I validated), or a weird error about an undefined method call (if not validated). Either way requires more work for regular code writing... While the case of wrong object type is rare enough to warrant application failure in case it happens - the case for scalar types is completely different. It was discussed many times on the list. I half disagree here. I disagree in the thought that the rarity should dictate the check. In fact, I would argue the exact opposite. That the more often an event happens, the more pressure there should be to fix it as it would fix more really odd bugs... In this case, I agree with you that I think strict scalar hinting would not actually solve the problem. But that doesn't mean a solution shouldn't be found. I really like Rasmus's concept of casting hints, where it would try to cast to an int and error only if it couldn't. Now, this surely would be very difficult to do in practice, and very hard to handle all the edge cases (especially when dealing with references, that could be HUGE). Anthony On Thu, Dec 22, 2011 at 2:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! What I mean is that you can catch recoverable fatal error in your error handler and at least be notified of what happened. Yes, you cannot go back in your script to corrent anything after that but you can show a detailed error message and send error email to developer. Just the same thing you can do when you hint class name for your input parameter - it will generate catchable fatal error if object is not an instance of expected class. Exactly, strict typing has same flaws everywhere, and this is exactly the reason it's not a solution for the problem it is presented to be - it does not make your code more robust or fail less or saves you effort on development - it just produces different error messages. While the case of wrong object type is rare enough to warrant application failure in case it happens - the case for scalar types is completely different. It was discussed many times on the list. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! I'm going to have to disagree with you there. Type hinting DOES save me a LOT of effort in development. I can stop worrying about checking to make sure the parameter that I got is what I want it to be, and just use it. The runtime will check and enforce that for me. When I'm sorry but I don't see how what you describe is good. You stopped worrying about checking inside the function, but unless you have started checking outside the function you've just made your code less robust that it was before. While in the case of strict class typing the case of mismatched classes is so rare that occasional failure is easily identifiable, you didn't really improve your code. I agree that it makes you type less - but the cost of it is your application also does less - you don't have a capability of gracefully handling a problem any longer. Again, with object strict typing, this might be OK since failures are very rare and usually a result of obvious mistakes caught early in testing - but if they are not, you didn't really gain much. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 3:06 PM, Stas Malyshev wrote: Hi! I'm going to have to disagree with you there. Type hinting DOES save me a LOT of effort in development. I can stop worrying about checking to make sure the parameter that I got is what I want it to be, and just use it. The runtime will check and enforce that for me. When I'm sorry but I don't see how what you describe is good. You stopped worrying about checking inside the function, but unless you have started checking outside the function you've just made your code less robust that it was before. While in the case of strict class typing the case of mismatched classes is so rare that occasional failure is easily identifiable, you didn't really improve your code. I agree that it makes you type less - but the cost of it is your application also does less - you don't have a capability of gracefully handling a problem any longer. Again, with object strict typing, this might be OK since failures are very rare and usually a result of obvious mistakes caught early in testing - but if they are not, you didn't really gain much. I wouldn't be opposed to moving from raising an E_RECOVERABLE_ERROR to some type of exception. In fact, I'd support it (in a discussion over that RFC). Your argument of not checkout outside the function is exactly why many are against type hinting scalars to begin with. A generic scalar keyword being added would help some, but only protect against objects, resources and arrays. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Return Type Hinting for Methods RFC
From: Paul Dragoonis [mailto:dragoo...@gmail.com]
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting,
and as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all
type checking up to the caller of the underlying functions/methods.
PHP is primarily a Web scripting language and the Web isn't typed.
Having stuff like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really
doesn't want to accept type-juggled arguments, then it is easy enough
to do a strict type check in the function itself. This puts the effort
in the correct place and doesn't encourage this type of coding.
I agree with Rasmus.
My opinion:
This isn't java, if you want a strongly typed language, there's plenty out
there, but we're not looking to make PHP more like Java and the rest, if it
was like Java then it wouldn't have been successful for the web as it is/was.
PHP is popular because of the way it was from the start, if php _needed_
scalar typehints then it wouldn't have been as popular.
There is need for the existing Typehinting for class types so you don't need
to have is_a() function calls. This makes sense.
Scalars are VERY powerful in PHP, because of its loose typed nature. Having a
'numeric' typehint makes sense, because it can be an int, float, or string.
Adding typehints like 'int' and 'float' will only piss people off, and make
PHP more difficult and less fluent to code in.
Lets not go there please..
Thanks,
Paul Dragoonis.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
Slightly off topic, but I keep seeing this problem:
PHP is not language X is a terrible argument. This is a smokescreen designed
to insult the other person, belittle their concerns, and avoid discussing the
real issue. This doesn't advance the discussion at all.
Concluding that PHP is popular because you can't {insert requested feature
here} is also ridiculous but it happens again and again whenever language
features are discussed. PHP is popular independent of not {insert missing
feature here}. It is popular because it was on the scene early, has good server
support, and does an excellent job of making it trivial to handle most simple
web requests.
Nobody wants to be told to shut up and go use language X.
Let's discuss things on their own merits.
/rant
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Dmitri Snytkine wrote: While web isn't typed, the php is not just for the web anymore, or is it? Some databases expect typed input, else the data is not found. For example passing string '1' instead of number 1 will not cause any errors when searching MongoDB but you will not get the result you expect to get if the value of key is integer 1 I think THIS is the ideal example on why we do not want to 'fix problems' in PHP just because something else does not work properly. If I pass a numeric value to a parameter in my database interface I do not worry about how that parameter was provided. I would treat the above example as a simply bug in MongoDB and is actually one of the reasons I have not bothered even looking at it as an alternative. If I am looking for an age do I want to limit people to 'years' ... 5 and a 1/2 is an acceptable age and may be generated automatically if I'm generating the data from a previously provided date of birth ... I prefer to provide errors myself when processing input like this, and that is always more appropriate IN the getter/setter that is handling the input. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
So, are we in agreement that, within the scope of this RFC, type hinting is
going to be limited to and match parameter type hinting?
On Dec 22, 2011, at 3:35 PM, John Crenshaw wrote:
From: Paul Dragoonis [mailto:dragoo...@gmail.com]
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting,
and as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all
type checking up to the caller of the underlying functions/methods.
PHP is primarily a Web scripting language and the Web isn't typed.
Having stuff like this break:
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really
doesn't want to accept type-juggled arguments, then it is easy enough
to do a strict type check in the function itself. This puts the effort
in the correct place and doesn't encourage this type of coding.
I agree with Rasmus.
My opinion:
This isn't java, if you want a strongly typed language, there's plenty out
there, but we're not looking to make PHP more like Java and the rest, if it
was like Java then it wouldn't have been successful for the web as it
is/was. PHP is popular because of the way it was from the start, if php
_needed_ scalar typehints then it wouldn't have been as popular.
There is need for the existing Typehinting for class types so you don't need
to have is_a() function calls. This makes sense.
Scalars are VERY powerful in PHP, because of its loose typed nature. Having
a 'numeric' typehint makes sense, because it can be an int, float, or
string. Adding typehints like 'int' and 'float' will only piss people off,
and make PHP more difficult and less fluent to code in.
Lets not go there please..
Thanks,
Paul Dragoonis.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit: http://www.php.net/unsub.php
Slightly off topic, but I keep seeing this problem:
PHP is not language X is a terrible argument. This is a smokescreen
designed to insult the other person, belittle their concerns, and avoid
discussing the real issue. This doesn't advance the discussion at all.
Concluding that PHP is popular because you can't {insert requested feature
here} is also ridiculous but it happens again and again whenever language
features are discussed. PHP is popular independent of not {insert missing
feature here}. It is popular because it was on the scene early, has good
server support, and does an excellent job of making it trivial to handle most
simple web requests.
Nobody wants to be told to shut up and go use language X.
Let's discuss things on their own merits.
/rant
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Your examples only show class methods with visibility qualifyiers, and looking at the changes to zend_language_parser.y it seems as if would only be available for methods. Wouldn't return hints be available for plain functions? In functional programming, it is common to return nullable types: returns an instance of class Foo or null, an array or false, etc. This is supported in normal arguments with the = null hint, and I think there should be something equivalent for return types. Does the proposed implementation allow null everywhere? (there's an example of returning null from a return hint of array) That seems wrong to me. Unless there's a way to make it strict (eg. array! for only arrays). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 10:41:28AM -0800, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs to be aligned with parameter type hinting, and
as has been pointed out many times on this list, type hinting for
interchangable scalar types is a really bad idea. It will push all type
checking up to the caller of the underlying functions/methods. PHP is
primarily a Web scripting language and the Web isn't typed. Having stuff
like this break:
I think that there are several problems with how we are discussing this:
a) we are confusing types with values.
PHP variables contain caues and are juggled where needed, thus this works:
$ten = '10';
$eleven = $ten + 1;
This is a great festure of PHP, works well in a web environment.
We don't care if $ten is a string or an integer. We seem to call the
type of this sort of variable a 'scalar'.
In more complicated programs we might want to constrain the type of
a variable - reduce surprise. The problem that we have is how to deal
with the interface, eg when a value in a scalar variable is assigned
to an integer variable. We have been thinking of these interfaces as being
entry to functions (as arguments), something needs to happen at
the interface. There are two ways:
function test(int $value) ...
test($ten)
This would fail - since $ten is a string
test($eleven)
would work.
We could make that value preserving in one of 2 ways, by the caller:
test((int)$ten)
That would work and give what we expect.
We could also specify that the function do it:
function test2((int) $value) ...
test2($ten)
Since $ten converts to integer cleanly.
But:
$fred = 'fred';
test2($fred)
would fail because you don't get clean conversion.
This would be in the spirit of PHP today. The API specification of test2()
would say that the argument must be numeric, ie the programmer must check it
before passing it in -- but we are talking about the value, not the type in
the strict manner.
b) the examples that we give are too simple. The benefits of knowing the type of
something is greatest within a ''package'', we only need to do type checking
at
the package interfaces (the published API) and can assume correctness on
internal
calls. We do get potential speedups if we know a type we don't need to do
type
juggling checks at runtime, the could be done at compile time:
function int MoreItems(int $items, (int) $more)
{
return $items + $more;
}
If a programmer does this then he will need to do explicit convertion:
function string HowManyMore(int $items)
{
// A cast '(string)' is not needed since the compiler knows that
$items is
// int and so needs a convertion:
return You have bought another . $items . items;
}
function void AddAnother($another)
{
if( !preg_match('/^\d+$/', $another))
throw new BadType(Another is bad);// or something
echo Howmany((int)$another);// User convertion
needed here
// Cast not needed since it happens in the function definition
$Total = MoreItems($Total, $another); // $Total is defined
somewhere
}
AddAnother($_POST['another']);
With bigger examples the advantages become apparent. But even the above is
contrived
and simple.
if(age_check($_POST['age'])) { do_stuff(); }
because the author of the age_check() function added an int type hint
just doesn't make any sense. It would cause everyone to have to start
casting things everywhere, just in case. eg.
if(age_check((int)$_POST['age'])) { do_stuff(); }
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the effort in the
correct place and doesn't encourage this type of coding.
No: the check is an assertion against something that should never happen.
A programmer could do checks at every place where he thinks that it is needed
(ie at the package interfaces), but there is always the small possibility that
something slips through the net and causes mayhem - this will stop it.
The other reason for having type checking is that it allows PHP compilers such
as hip-hop to do more global optimisatons ... removing checking completely if it
knows everywhere a function (probably a class method) can be called from and
knows
the types of the arguments that are passed in to it.
--
Alain Williams
Linux/GNU Consultant -
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Sent from my iPad On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote: Your examples only show class methods with visibility qualifyiers, and looking at the changes to zend_language_parser.y it seems as if would only be available for methods. Wouldn't return hints be available for plain functions? Right now, it's only available for methods. Personally, I'm not a fan of return types for functions. Adding this for functions in its form today will also introduce shift/reduce issues. In functional programming, it is common to return nullable types: returns an instance of class Foo or null, an array or false, etc. This is supported in normal arguments with the = null hint, and I think there should be something equivalent for return types. Does the proposed implementation allow null everywhere? (there's an example of returning null from a return hint of array) That seems wrong to me. Unless there's a way to make it strict (eg. array! for only arrays). Most modern languages allow returning null in any case. This is a hail Mary in the event something happens, but throwing an exception is inappropriate. I see no reason to diverge from that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 06:08:26PM -0500, Will Fitch wrote: Most modern languages allow returning null in any case. This is a hail Mary in the event something happens, but throwing an exception is inappropriate. I see no reason to diverge from that. Agreed, it is often convenient to return NULL or FALSE to indicate failure or something like end of input (think: fgetc()). I was mulling syntax like: function (string|boolean:false) fgetc(resource $handle) Then the compiler would know that after: if( ($ch = fgetc($in)) === FALSE) return; that $ch is string ... but seems too complicated. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, 22 Dec 2011, Will Fitch wrote:
On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote:
I think the return type hinting really depends on variable type hinting.
A simple example whould bea typical getter function
public function \Customer getCustomer(){
return $this-customer;
}
The actual syntax would be:
public \Customer getCustomer()
Really? I saw this in the RFC when I skimmed over it, but presumed that
to be a mistake. I do not see it as a great idea to remove the
function part as it's *so* PHP right now.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! Most modern languages allow returning null in any case. This is a hail Mary in the event something happens, but throwing an exception is inappropriate. I see no reason to diverge from that. In PHP, returning object if everything is OK and false if not is a very common pattern. Also, you understand that always allowing null means that this construct: $foo = $this-returnsFoo(); $foo-fooMethod(); is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, 22 Dec 2011, Will Fitch wrote: Sent from my iPad On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote: Your examples only show class methods with visibility qualifyiers, and looking at the changes to zend_language_parser.y it seems as if would only be available for methods. Wouldn't return hints be available for plain functions? Right now, it's only available for methods. Personally, I'm not a fan of return types for functions. Adding this for functions in its form today will also introduce shift/reduce issues. IMO, it should work for normal functions too. In functional programming, it is common to return nullable types: returns an instance of class Foo or null, an array or false, etc. This is supported in normal arguments with the = null hint, and I think there should be something equivalent for return types. Does the proposed implementation allow null everywhere? (there's an example of returning null from a return hint of array) That seems wrong to me. Unless there's a way to make it strict (eg. array! for only arrays). Most modern languages allow returning null in any case. This is a hail Mary in the event something happens, but throwing an exception is inappropriate. I see no reason to diverge from that. I tend to agree with that one. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Most modern languages allow returning null in any case. This is a hail Mary in the event something happens, but throwing an exception is inappropriate. I see no reason to diverge from that. In PHP, returning object if everything is OK and false if not is a very common pattern. Also, you understand that always allowing null means that this construct: $foo = $this-returnsFoo(); $foo-fooMethod(); is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway. Are you suggesting not allowing null to be returned, or provide an indicator within the syntax that it may return null? PHP would be the first language I'm aware of that would do so in either case. The point isn't to restrict a type hint to always be returned. The goal is to guarantee that if a value is returned, it will be of type X. In the event it is inappropriate to return the value back, would you rather receive null or a bogus class instance, empty array or a random function name back? Because that's what will happen. It will become the workaround for not being able to return null. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! Are you suggesting not allowing null to be returned, or provide an indicator within the syntax that it may return null? PHP would be the first language I'm aware of that would do so in either case. No I am not suggesting that. I'm just pointing out the problems with the concept of strict typing in PHP and this particular instance of it. One of them is that many functions do not actually return one type but multiple types depending on the result. It is a very common pattern. BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl, Javascript (to some measure), etc. don't have typing as far as I know. Comparing PHP to statically compiled strictly typed languages does not seem very useful to me. So could you clarify what do you mean? The point isn't to restrict a type hint to always be returned. The goal is to guarantee that if a value is returned, it will be of type X. In the event it is inappropriate to return the value back, would All functions in PHP return values, so it is not possible that no value would be returned (yes, if you don't return anything it actually will return null). So ensuring something is an object of type X prevents you from returning anything else, false/null included. If you make exceptions for null, then why not for false? If for false, then why not for true? Etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 23/12/11 00:08, Will Fitch wrote:
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available for methods. Wouldn't return
hints be available for plain functions?
Right now, it's only available for methods. Personally, I'm not a fan
of return types for functions. Adding this for functions in its form
today will also introduce shift/reduce issues.
Yes, it's much easier for the parser for methods with explicit
visibility (note that public is optional).
I'm ok on requiring the public for methods with a return hint, but if
methods can get return hints,
normal functions must, too.
If it's hard with your proposed syntax, it should be discarded and a
better one developed.
Else we would end up with different syntaxes for return hints depending
on the kind of function.
For instance, the return hint could go at the end of the prototype:
function foo (Class1 $a, Class2 $b) = Class3 {
return new Class3($a, $b);
}
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
In functional programming, it is common to return nullable types:
returns an instance of class Foo or null, an array or false, etc.
This is supported in normal arguments with the = null hint, and I
think there should be something equivalent for return types.
Does the proposed implementation allow null everywhere? (there's an
example of returning null from a return hint of array)
That seems wrong to me. Unless there's a way to make it strict (eg.
array! for only arrays).
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
I disagree with you, but Stas already provided a compelling case.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 23/12/11 01:00, Will Fitch wrote: On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote: In PHP, returning object if everything is OK and false if not is a very common pattern. Also, you understand that always allowing null means that this construct: $foo = $this-returnsFoo(); $foo-fooMethod(); is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway. Are you suggesting not allowing null to be returned, or provide an indicator within the syntax that it may return null? It should be possible to allow it. Either with a generic syntax for allowing many types of return types or through a specific one (eg. in C# a ? marks an internal type as nullable: int? ) PHP would be the first language I'm aware of that would do so in either case. It already barfs at you if you pass null to a parameter expecting a given class (though you can allow it). The point isn't to restrict a type hint to always be returned. The goal is to guarantee that if a value is returned, it will be of type X. In the event it is inappropriate to return the value back, would you rather receive null or a bogus class instance, empty array or a random function name back? Because that's what will happen. It will become the workaround for not being able to return null. As it would support both ways, it's up to the framework to choose if they want to return null or a fake-class interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi: On 23 Dec 2011, at 01:14, Stas Malyshev wrote: BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl, Javascript (to some measure), etc. don't have typing as far as I know. Comparing PHP to statically compiled strictly typed languages does not seem very useful to me. So could you clarify what do you mean? Perhaps the newest kid on the block deserves some reference for making optional typing more mainstream and being more radical about being checkable documentation: http://www.dartlang.org/docs/technical-overview/index.html Dart's type system is not sound, and the design goal is to never (NEVER) interfere with execution semantics. It is more radical than previous research systems with its not-sound approach of making generics understandable, but people seem to appreciate that in practice. It might give the necessary example to bridge the worlds between the 'PHP should be more like Java' and the 'PHP should be more like PHP' people. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Sent from my iPhone On Dec 22, 2011, at 7:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Are you suggesting not allowing null to be returned, or provide an indicator within the syntax that it may return null? PHP would be the first language I'm aware of that would do so in either case. No I am not suggesting that. I'm just pointing out the problems with the concept of strict typing in PHP and this particular instance of it. One of them is that many functions do not actually return one type but multiple types depending on the result. It is a very common pattern. And in those cases, they would continue to use the keyword function and be considered unknown as they are today. BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl, Javascript (to some measure), etc. don't have typing as far as I know. Comparing PHP to statically compiled strictly typed languages does not seem very useful to me. So could you clarify what do you mean? Not seem useful? Then during the discussions of parameter type hinting, which language did you compare it to? What about abstracts and interfaces? I don't compare PHP to ruby, python or JavaScript. Do I suggest features that I find useful in other languages like C# or Java or even in any of the ones you listed? Absolutely. Limiting yourself to comparing features only found in interpreted languages is a very narrowed scope. Yes, return type validation does add overhead, just as parameters do (arguably more). But it is a feature that is very valuable to many. Those who wish not to use it can continue to do so. Don't forget that while return checks are runtime, interface definition and implementations are compile time. The point isn't to restrict a type hint to always be returned. The goal is to guarantee that if a value is returned, it will be of type X. In the event it is inappropriate to return the value back, would All functions in PHP return values, so it is not possible that no value would be returned (yes, if you don't return anything it actually will return null). So ensuring something is an object of type X prevents you from returning anything else, false/null included. If you make exceptions for null, then why not for false? If for false, then why not for true? Etc. Because null is a standard already set by parameter type hints. I do not want to sway away from that as it works well. It is common for null values to be considered nothing, which is exactly what will be returned if the specified hint isn't. All or nothing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi! And in those cases, they would continue to use the keyword function and be considered unknown as they are today. Taking the most common case and ignoring it and saying ok, then don't use it is not a good way to design a feature in a general-purpose language that would be used by literally millions. I don't compare PHP to ruby, python or JavaScript. Do I suggest features that I find useful in other languages like C# or Java or even in any of the ones you listed? Absolutely. C# and Java, again, are fully statically typed compiled languages. PHP is not. That means that the benefits of strict type system that are available to programmers in C# or Java will not be available to PHP programmers, while the downsides of it (and inflexibility that such system leads to) will still be there and will actually be multiplied by the fact that you wouldn't know about the problem with your typing system until your application starts crashing. add overhead, just as parameters do (arguably more). But it is a feature that is very valuable to many. Those who wish not to use it can continue to do so. Sorry, again, don't use it is not a valid response for a core feature in a widely used language. It would be OK for a PECL module - if you don't like mongoDB, don't use it, nobody objects to having mongodb extension because it is not fit for some scenarios. However, designing core language features that change the nature of the language - making it from non-typed to strictly typed - have bigger requirements. You can not just not use core feature - because others will be using it and you'd have to leave with it and interface with their code. Don't forget that while return checks are runtime, interface definition and implementations are compile time. Nothing is compile time in PHP, PHP has no compile time (at least if we don't consider projects like HipHop, which is totally irrelevant here) like C# or Java does. That's not how PHP code works. In C# and Java, you can take the code and know in advance the type of any piece of data in any place (maybe not precisely but at least base type). In PHP, you can not. Because null is a standard already set by parameter type hints. I do not want to sway away from that as it works well. It is common for I'm not sure what you're talking about as a standard. Yes, input parameters strict typing allows nulls because it was another frequently used scenario that strict typing does not support. Fortunately, it could be fit into default value syntax, even though it doesn't really means that (so we actually have a syntax that means two different things now, not a great idea). But with return types and value strict types (which would inevitably be asked for next) it wouldn't be that easy. There's no syntax for default return value and the case of returning false - one of the most common - can not be covered. And, on top of that, I still do not see any benefit of it as you'd still have to check the return value anyway! -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote: Hi! And in those cases, they would continue to use the keyword function and be considered unknown as they are today. Taking the most common case and ignoring it and saying ok, then don't use it is not a good way to design a feature in a general-purpose language that would be used by literally millions. The feature isn't designed around only those who use it. In fact, as per the RFC, the keyword function will be used to serve as a mixed return type. There are cases where I don't want to type hint my return value from a method and will continue to use this. All scalar values will be forced to use this way anyway. Namespaces, interfaces, abstracts, closures, traits. the list goes on with features that were built to give developers additional tools to use. Are any of them required to use? No. It's general purpose - just like the feature offered here. How many features are built into PHP that are meant to force a user to use it, or even break BC? Why would you suggest this is doing any different? Can you provide an example where this feature is doing that? I don't compare PHP to ruby, python or JavaScript. Do I suggest features that I find useful in other languages like C# or Java or even in any of the ones you listed? Absolutely. C# and Java, again, are fully statically typed compiled languages. PHP is not. That means that the benefits of strict type system that are available to programmers in C# or Java will not be available to PHP programmers, while the downsides of it (and inflexibility that such system leads to) will still be there and will actually be multiplied by the fact that you wouldn't know about the problem with your typing system until your application starts crashing. Are you saying parameter type hinting isn't in PHP? add overhead, just as parameters do (arguably more). But it is a feature that is very valuable to many. Those who wish not to use it can continue to do so. Sorry, again, don't use it is not a valid response for a core feature in a widely used language. It would be OK for a PECL module - if you don't like mongoDB, don't use it, nobody objects to having mongodb extension because it is not fit for some scenarios. However, designing core language features that change the nature of the language - making it from non-typed to strictly typed - have bigger requirements. You can not just not use core feature - because others will be using it and you'd have to leave with it and interface with their code. Sorry, again, look at what I said above. Namespaces, interfaces, abstracts, closures, traits, parameter type hints, even classes are core features that users aren't forced to use. Please tell me what makes them different. It is an optional feature - just like all those I listed. If others are using it, that's the point. Can you walk into existing code that you must interface with today that has a type hinted parameter and decide not to use it? No. Why? Because the company/developer who developed that solution made the decision that it was a feature they found useful. What you're suggesting is that we design features around those who do not want to use it. Don't forget that while return checks are runtime, interface definition and implementations are compile time. Nothing is compile time in PHP, PHP has no compile time (at least if we don't consider projects like HipHop, which is totally irrelevant here) like C# or Java does. That's not how PHP code works. In C# and Java, you can take the code and know in advance the type of any piece of data in any place (maybe not precisely but at least base type). In PHP, you can not. So Java's bytecode, which requires a VM (interpreter), isn't comparable to PHP's compile? Are you saying compile is only when code is converted into machine code? Moving PHP code through a lexical analyzer, syntax parser, intermediate code generator/opcode isn't a form of compilation? Considering the verification of interfaces is done during the syntax parser, in a file called zend_compile.c, before the code is actually executed, I'm pretty comfortable calling this transformation compiled. Because null is a standard already set by parameter type hints. I do not want to sway away from that as it works well. It is common for I'm not sure what you're talking about as a standard. Yes, input parameters strict typing allows nulls because it was another frequently used scenario that strict typing does not support. Fortunately, it could be fit into default value syntax, even though it doesn't really means that (so we actually have a syntax that means two different things now, not a great idea). But with return types and value strict types (which would inevitably be asked for next) it wouldn't be that easy. There's no syntax for default return value and the case of returning false -
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 7:21 PM, Ángel González wrote:
On 23/12/11 00:08, Will Fitch wrote:
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available for methods. Wouldn't return
hints be available for plain functions?
Right now, it's only available for methods. Personally, I'm not a fan
of return types for functions. Adding this for functions in its form
today will also introduce shift/reduce issues.
Yes, it's much easier for the parser for methods with explicit
visibility (note that public is optional).
I'm ok on requiring the public for methods with a return hint, but if
methods can get return hints,
normal functions must, too.
If it's hard with your proposed syntax, it should be discarded and a
better one developed.
Else we would end up with different syntaxes for return hints depending
on the kind of function.
It's not a matter of being difficult. I can see your argument, however.
For instance, the return hint could go at the end of the prototype:
function foo (Class1 $a, Class2 $b) = Class3 {
return new Class3($a, $b);
}
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
Let me see what can be done without doing too much to the definitions. I like
the idea of not making function required.
In functional programming, it is common to return nullable types:
returns an instance of class Foo or null, an array or false, etc.
This is supported in normal arguments with the = null hint, and I
think there should be something equivalent for return types.
Does the proposed implementation allow null everywhere? (there's an
example of returning null from a return hint of array)
That seems wrong to me. Unless there's a way to make it strict (eg.
array! for only arrays).
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
I disagree with you, but Stas already provided a compelling case.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Dec 22, 2011, at 7:33 PM, Ángel González wrote: On 23/12/11 01:00, Will Fitch wrote: On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote: In PHP, returning object if everything is OK and false if not is a very common pattern. Also, you understand that always allowing null means that this construct: $foo = $this-returnsFoo(); $foo-fooMethod(); is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway. Are you suggesting not allowing null to be returned, or provide an indicator within the syntax that it may return null? It should be possible to allow it. Either with a generic syntax for allowing many types of return types or through a specific one (eg. in C# a ? marks an internal type as nullable: int? ) You can return null from methods. Parameters and variables are nullable. I'm not against appending an indicator as to whether null may be returned, but that would need to be a general consensus, I think. I would like other opinions on this... PHP would be the first language I'm aware of that would do so in either case. It already barfs at you if you pass null to a parameter expecting a given class (though you can allow it). The point isn't to restrict a type hint to always be returned. The goal is to guarantee that if a value is returned, it will be of type X. In the event it is inappropriate to return the value back, would you rather receive null or a bogus class instance, empty array or a random function name back? Because that's what will happen. It will become the workaround for not being able to return null. As it would support both ways, it's up to the framework to choose if they want to return null or a fake-class interface. Yes, it would. But providing the option of null would be a good incentive not to do that. At the end of the day, you're giving a set of tools to someone. If they choose to use it in a way that's less efficient, or wrong in other's eyes, that's their choice. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
I will update to take functions into consideration. Will let you know when the
RFC/patch reflect it.
On Dec 22, 2011, at 7:44 PM, Ángel González wrote:
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to return null
at will, or add a marker noting that it *may* return null?
Example: Return null at will
public ArrayIterator getIterator()
{
// something happened, will return null
return null;
}
Example: Return only if identified as such
public ArrayIterator? getIterator()
{
return null;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Will add tonight and generate a new patch. On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote: hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi Pierre and Nikita, I have added callable to the patch and updated the RFC entry to reflect the changes. Please verify and let me know if you have any issues. On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote: hi Will, You should add it now, while 5.4 final is not released yet, this feature exists already and should be part of the RFC, to be complete. Cheers, On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote: Hi Nikita, I didn't add that as it's not yet in production. As soon as things are finalized and 5.4 is GA, I will gladly add the callable type hint. The change wouldn't be different from parameter type hinting, and can easily be added. On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote: Hi Will! One random thought I had while reading the RFC is: What about the newly introduced callable typehint? Is this missing by intention? I could well imagine so (because it's hard to check what scope callability should be checked on), but wanted to be sure on that. Nikita On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Return Type Hinting for Methods RFC
Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/20/2011 06:09 PM, Will Fitch wrote: Hello All, I would like to submit https://wiki.php.net/rfc/returntypehint2 into discussion. A link to the patch for this is provided and can be ran against the current HEAD. There is an older entry still in existence, but this patch is syntactically different. The older entry is located at https://wiki.php.net/rfc/typechecking and is bundled with parameter, scalars, etc. If possible, can someone promote this to the Under Discussion category within https://wiki.php.net/rfc? -- Will I've added it to https://wiki.php.net/rfc/typechecking with the other related RFCs. This is linked from the Under Discussion section. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
