Return Type Hinting for Methods RFC

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by Christopher Jones — view source — reply

unread

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.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

14 years ago by Nikita Popov — view source — reply

unread

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

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

14 years ago by Will Fitch — view source — reply

unread

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.

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

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

14 years ago by Pierre Joye — view source — reply

unread

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,

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.

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

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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Will Fitch — view source — reply

unread

Will add tonight and generate a new patch.

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,

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.

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

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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Will Fitch — view source — reply

unread

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.

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,

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.

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

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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Will Fitch [mailto:will.fitch@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.

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,

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.

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.fitch@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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Sebastian Krebs — view source — reply

unread

2011/12/22 Dmitri Snytkine dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Will Fitch [mailto:will.fitch@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.

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.fitch@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.

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.fitch@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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Alain Williams — view source — reply

unread

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

14 years ago by Alain Williams — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Will Fitch [mailto:will.fitch@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.

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,

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.

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.fitch@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

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by keisial@gmail.com — view source — reply

unread

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).

14 years ago by Will Fitch — view source — reply

unread

Sent from my iPad

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.

14 years ago by Alain Williams — view source — reply

unread

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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Stefan Marr — view source — reply

unread

Hi:

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

14 years ago by Will Fitch — view source — reply

unread

Sent from my iPhone

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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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 - 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!

public function blah(SomeClass $class = null)
{
if ($class)
{
// code here
}
}

What I'm calling a "standard" is something already in the language. If I had written this to allow "false" to be returned instead of null, the complaints would be much greater. Why? Because we're used to the type hinting allowing that.

I want to make it clear that my goal with this RFC isn't to offer a compile time feature for the sake of having it. Because PHP is interpreted and we have our on minds, we can make decisions such as the frequently used scenario you mentioned above. If the general consensus is that you must return the type declared, then I'm game for it. In fact, code execution would actually be faster. But what will end up happening is this:

public array getArray()
{
// Uh oh, I'll have to return an empty array
return array();
}

$array_value = $obj->getArray();

if (!empty($array_value))

This is why I decided on the null option.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

14 years ago by Will Fitch — view source — reply

unread

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;
}

14 years ago by Robert Williams — view source — reply

unread

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 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).

14 years ago by John Crenshaw — view source — reply

unread

From: Will Fitch [mailto:will.fitch@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.

14 years ago by ar@ez.no — view source — reply

unread

2011/12/23 John Crenshaw johncrenshaw@priacta.com

From: Will Fitch [mailto:will.fitch@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 Nullable<System.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.

14 years ago by Will Fitch — view source — reply

unread

Sent from my iPhone

2011/12/23 John Crenshaw johncrenshaw@priacta.com

From: Will Fitch [mailto:will.fitch@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 Nullable<System.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.

14 years ago by Will Fitch — view source — reply

unread

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.

2011/12/23 John Crenshaw johncrenshaw@priacta.com

From: Will Fitch [mailto:will.fitch@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 Nullable<System.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.

14 years ago by ar@ez.no — view source — reply

unread

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.

2011/12/23 John Crenshaw johncrenshaw@priacta.com

From: Will Fitch [mailto:will.fitch@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 Nullable<System.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!

14 years ago by keisial@gmail.com — view source — reply

unread

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.

14 years ago by Will Fitch — view source — reply

unread

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.

14 years ago by Derick Rethans — view source — reply

unread

Sent from my iPad

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

14 years ago by keisial@gmail.com — view source — reply

unread

Sent from my iPad

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.

14 years ago by keisial@gmail.com — view source — reply

unread

(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);
}

14 years ago by Will Fitch — view source — reply

unread

I will update to take functions into consideration. Will let you know when the RFC/patch reflect it.

(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);
}

14 years ago by Will Fitch — view source — reply

unread

Sent from my iPad

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.

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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

14 years ago by Nikita Popov — view source — reply

unread

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
dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Keloran — view source — reply

unread

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 <
dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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

14 years ago by Ferenc Kovacs — view source — reply

unread

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..

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 <
dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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>

--

--

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

14 years ago by Rasmus Lerdorf — view source — reply

unread

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

14 years ago by Paul Dragoonis — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by John Crenshaw — view source — reply

unread

From: Paul Dragoonis [mailto:dragoonis@gmail.com]

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

--
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.

14 years ago by Will Fitch — view source — reply

unread

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?

From: Paul Dragoonis [mailto:dragoonis@gmail.com]

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

--
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.

14 years ago by Sebastian Bergmann — view source — reply

unread

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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Rasmus Lerdorf — view source — reply

unread

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

14 years ago by Matthew Weier O'Phinney — view source — reply

unread

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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

14 years ago by Will Fitch — view source — reply

unread

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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by Rasmus Lerdorf — view source — reply

unread

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

14 years ago by Alain Williams — view source — reply

unread

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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@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
dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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

14 years ago by Oleg Oshmyan — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@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
dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Alain Williams [mailto:addw@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

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

14 years ago by Derick Rethans — view source — reply

unread

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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@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

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

14 years ago by Lester Caine — view source — reply

unread

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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@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

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

14 years ago by Rasmus Lerdorf — view source — reply

unread

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

14 years ago by John Crenshaw — view source — reply

unread

From: Rasmus Lerdorf [mailto:rasmus@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.

14 years ago by Rasmus Lerdorf — view source — reply

unread

From: Rasmus Lerdorf [mailto:rasmus@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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Anthony Ferrara — view source — reply

unread

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

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

14 years ago by Stas Malyshev — view source — reply

unread

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

14 years ago by Will Fitch — view source — reply

unread

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

14 years ago by Dmitri Snytkine — view source — reply

unread

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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Ángel González [mailto:keisial@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);
}

14 years ago by Clint M Priest — view source — reply

unread

That syntax is pretty readable, would there be alternatives such as:

function foo() returns Class3, array or null {
}

-----Original Message-----
From: Dmitri Snytkine [mailto:dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Ángel González [mailto:keisial@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);
}

14 years ago by Will Fitch — view source — reply

unread

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

That syntax is pretty readable, would there be alternatives such as:

function foo() returns Class3, array or null {
}

-----Original Message-----
From: Dmitri Snytkine [mailto:dsnytkine@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: dsnytkine@ultralogistics.com
Web: www.ultralogistics.com

"A Top 100 Logistics I.T. Provider in 2011"

-----Original Message-----
From: Ángel González [mailto:keisial@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);
}

Return Type Hinting for Methods RFC View as Markdown

-- Will

-- Will

-- Will

-- Will

-- Will

-- Will

is no longer safe as you wanted it to be when you made returnsFoo use strict typing? You'd have to check $foo anyway.

cheers, Derick

-- Lester Caine - G8HFL

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.

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.

is no longer safe as you wanted it to be when you made returnsFoo use
strict typing? You'd have to check $foo anyway.

cheers,
Derick

--
Lester Caine - G8HFL

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.

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.