On 2011-12-22, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really
doesn't want to accept type-juggled arguments, then it is easy
enough
. Provider in 2011
-Original Message-
From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com]
Sent: Tuesday, December 27, 2011 11:12 AM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
I'm sorry but even though I liked that RFC, I'd like
Logistics I.T. Provider in 2011
-Original Message-
From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com]
Sent: Tuesday, December 27, 2011 11:12 AM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
I'm sorry but even though I liked
I'm sorry but even though I liked that RFC, I'd like to ask about type
hinting through annotations. Has anyone considered that? I think that it
would be nice because it also docs the functions at the same time.
To be honest I don't know even if that's possible. So, it's just a thought.
On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch will.fi...@gmail.com wrote:
In the interest of providing options for an ability to mark a method as
returning null, I have added a new patch here:
http://www.willfitch.com/php/nullable.patch
This includes a new token T_NULLABLE. Here are a few
The RFC and patch has been updated to include the nullable functionality that
addresses the concerns mentioned by Stas.
https://wiki.php.net/rfc/returntypehint2
On Dec 23, 2011, at 5:02 PM, Will Fitch wrote:
I have updated the RFC and patch to reflect not allowing null to be returned
On Dec 22, 2011, at 18:59, Will Fitch will.fi...@gmail.com wrote:
Would you prefer to allow methods with type hinted return values to return
null at will, or add a marker noting that it *may* return null?
My preference would be to have a marker, and when null is not allowed, if the
function
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to return
null at will, or add a marker noting that it *may* return null?
Example: Return null at will
public
[mailto:keis...@gmail.com]
Sent: Thursday, December 22, 2011 7:45 PM
To: PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm
List'
Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider
González'; 'PHP Developers Mailing List'
Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC
Is this how it's done in Scala?
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
Phone: (888) 220-4640 x 2097
Fax: (888) 795-6642
E-Mail: dsnytk...@ultralogistics.com
Web
On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote:
There's still the matter of whether allowing null to be returned,
regardless of the situation, or using another token to identify that
it could return null. I'd like to know what others think. I see Stas'
argument that you'll still have
On Dec 23, 2011, at 4:29 PM, Robert Williams wrote:
On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote:
There's still the matter of whether allowing null to be returned,
regardless of the situation, or using another token to identify that
it could return null. I'd like to know what
I have updated the RFC and patch to reflect not allowing null to be returned
unconditionally. With the current patch, I have not added any type of
indicator to allow null to be returned at all. This will allow us to discuss
things one at a time and determine whether we actually want an
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type hinted return values to
return null at will, or add a marker noting that it *may*
Sent from my iPhone
On Dec 23, 2011, at 6:32 PM, André Rømcke a...@ez.no wrote:
2011/12/23 John Crenshaw johncrens...@priacta.com
From: Will Fitch [mailto:will.fi...@gmail.com]
I would like to take this opportunity to query on a consensus:
Would you prefer to allow methods with type
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()
{
-Original Message-
From: Will Fitch [mailto:will.fi...@gmail.com]
Sent: Wednesday, December 21, 2011 5:29 PM
To: Pierre Joye
Cc: Nikita Popov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi Pierre and Nikita,
I have added callable to the patch
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Hi Pierre and Nikita,
I have added callable to the patch and updated the RFC entry to reflect the
changes. Please verify and let me know if you have any issues.
On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:
hi Will,
You
On Thu, Dec 22, 2011 at 09:09:40AM -0500, Dmitri Snytkine wrote:
The return type hinting is probably the biggest thing happening in php in a
long time.
Is this too good to be true?
With return type hinting I can see a huge improvenets in php IDEs in
spotting errors. Also it will be much
: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Will Fitch [mailto:will.fi...@gmail.com]
Sent: Wednesday, December 21, 2011 5:29 PM
To: Pierre Joye
Cc: Nikita Popov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Return Type Hinting
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject $customers;
Once more Why is PHP not Java?
That comment confuses matters. People use PHP for all sorts of reasons, the
desire to tighten up in some places, on some occasions, should not be treated
with
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
private \ArrayObject
: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011
. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote
Message-
From: Nikita Popov [mailto:nikita@googlemail.com]
Sent: Thursday, December 22, 2011 10:02 AM
To: Dmitri Snytkine
Cc: Alain Williams; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
Could we maybe keep this discussion contained to return value type
On Thu, Dec 22, 2011 at 09:59:16AM -0500, Dmitri Snytkine wrote:
I never said to make it mandatory, only to make it available. Just like the
type hinting of function call is optional but not mandatory, which is a big
advantage over Java in my opinion.
After all, if you make return type
100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On Thu, Dec 22, 2011 at 03:33:40PM +0100
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
...@ultralogistics.com
Web: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Alain Williams [mailto:a...@phcomp.co.uk]
Sent: Thursday, December 22, 2011 9:52 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods
On Dec 22, 2011, at 10:18 AM, Oleg Oshmyan wrote:
public function \Customer getCustomer(){
return $this-customer;
}
If the $customer instance variable is not declared with the type Customer
then first of all IDE will not be able to spot an error, second compiler may
have a slighly harder
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
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
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) { return 5; }
return 99;
}
Return type hinting needs
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool
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
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
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Thursday, December 22, 2011 1:41 PM
To: Keloran
Cc: Dmitri Snytkine; Alain Williams; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 07:08 AM, Keloran wrote:
i would love
] 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
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This puts the
On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
if ($tester) {
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
On 12/22/2011 11:18 AM, Will Fitch wrote:
On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int
-DEV] Return Type Hinting for Methods RFC
On 12/22/2011 10:51 AM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check
On Dec 22, 2011, at 1:50 PM, Paul Dragoonis wrote:
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it could be
On Dec 22, 2011, at 1:51 PM, Sebastian Bergmann wrote:
Am 22.12.2011 19:41, schrieb Rasmus Lerdorf:
This is not a step forward. If the author of age_check() really doesn't
want to accept type-juggled arguments, then it is easy enough to do a
strict type check in the function itself. This
: www.ultralogistics.com
A Top 100 Logistics I.T. Provider in 2011
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Thursday, December 22, 2011 2:19 PM
To: Dmitri Snytkine
Cc: 'Sebastian Bergmann'; internals@lists.php.net
Subject: Re: [PHP-DEV] Return Type Hinting
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
On 12/22/2011 11:20 AM, Dmitri Snytkine wrote:
Not sure what you mean by json wrapped.
In mongo you do $coll-find(array('age' = $age);
if $age is a string '21' your will not get any erros but neither will you
get any results.
It is json underneath, but in your find() example, obviously the
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
How is that hard?
function age_lookup($age) {
return $coll-find(array('age' = (int)$age);
}
but again here, doing a strong type check on the parameter isn't making your
life easier. It simply pushes the responsibility to the
On 12/22/2011 11:49 AM, John Crenshaw wrote:
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
How is that hard?
function age_lookup($age) {
return $coll-find(array('age' = (int)$age);
}
but again here, doing a strong type check on the parameter isn't making your
life easier.
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
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
On Dec 22, 2011, at 3:06 PM, Stas Malyshev wrote:
Hi!
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checking
to make sure the parameter that I got is what I want it to be, and
just use it. The runtime
From: Paul Dragoonis [mailto:dragoo...@gmail.com]
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on
function
variables was supposed to be), so that it
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
So, are we in agreement that, within the scope of this RFC, type hinting is
going to be limited to and match parameter type hinting?
On Dec 22, 2011, at 3:35 PM, John Crenshaw wrote:
From: Paul Dragoonis [mailto:dragoo...@gmail.com]
On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf
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:
On Thu, Dec 22, 2011 at 10:41:28AM -0800, Rasmus Lerdorf wrote:
On 12/22/2011 07:08 AM, Keloran wrote:
i would love to see this expanded aswell (the way type hinting on function
variables was supposed to be), so that it could be
string, int
e.g.
function int test(bool $tester) {
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available for methods. Wouldn't return
hints be available
On Thu, Dec 22, 2011 at 06:08:26PM -0500, Will Fitch wrote:
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
Agreed, it is often convenient to return
On Thu, 22 Dec 2011, Will Fitch wrote:
On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote:
I think the return type hinting really depends on variable type hinting.
A simple example whould bea typical getter function
public function \Customer getCustomer(){
return $this-customer;
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
On Thu, 22 Dec 2011, Will Fitch wrote:
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available
On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
In PHP, returning
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
On 23/12/11 00:08, Will Fitch wrote:
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to zend_language_parser.y
it seems as if would only be available for
On 23/12/11 01:00, Will Fitch wrote:
On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
In PHP, returning object if everything is OK and false if not is a very
common pattern.
Also, you understand that always allowing null means that this construct:
$foo =
Hi:
On 23 Dec 2011, at 01:14, Stas Malyshev wrote:
BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl,
Javascript (to some measure), etc. don't have typing as far as I know.
Comparing PHP to statically compiled strictly typed languages does not seem
very useful to
Sent from my iPhone
On Dec 22, 2011, at 7:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Are you suggesting not allowing null to be returned, or provide an
indicator within the syntax that it may return null? PHP would be the
first language I'm aware of that would do so in either
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm unconvinced on which)
What about this?
function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
}
--
PHP
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
On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote:
Hi!
And in those cases, they would continue to use the keyword function
and be considered unknown as they are today.
Taking the most common case and ignoring it and saying ok, then don't use
it is not a good way to design a feature in a
On Dec 22, 2011, at 7:21 PM, Ángel González wrote:
On 23/12/11 00:08, Will Fitch wrote:
Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com wrote:
Your examples only show class methods with visibility qualifyiers, and
looking at the changes to
On Dec 22, 2011, at 7:33 PM, Ángel González wrote:
On 23/12/11 01:00, Will Fitch wrote:
On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
In PHP, returning object if everything is OK and false if not is a very
common pattern.
Also, you understand that always allowing
I will update to take functions into consideration. Will let you know when the
RFC/patch reflect it.
On Dec 22, 2011, at 7:44 PM, Ángel González wrote:
(I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
should be some token there
before the class name, though I'm
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,
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,
Hi Nikita,
I didn't add that as it's not yet in production. As soon as things are
finalized and 5.4 is GA, I will gladly add the callable type hint. The change
wouldn't be different from parameter type hinting, and can easily be added.
On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
Hi
hi Will,
You should add it now, while 5.4 final is not released yet, this
feature exists already and should be part of the RFC, to be complete.
Cheers,
On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch will.fi...@gmail.com wrote:
Hi Nikita,
I didn't add that as it's not yet in production. As soon
Will add tonight and generate a new patch.
On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:
hi Will,
You should add it now, while 5.4 final is not released yet, this
feature exists already and should be part of the RFC, to be complete.
Cheers,
On Wed, Dec 21, 2011 at 6:22 PM, Will
Hi Pierre and Nikita,
I have added callable to the patch and updated the RFC entry to reflect the
changes. Please verify and let me know if you have any issues.
On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:
hi Will,
You should add it now, while 5.4 final is not released yet, this
On 12/20/2011 06:09 PM, Will Fitch wrote:
Hello All,
I would like to submit https://wiki.php.net/rfc/returntypehint2 into
discussion. A link to the patch for this is provided and can be ran against
the current HEAD.
There is an older entry still in existence, but this patch is
83 matches
Mail list logo
