Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names are supported for both
parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.
function myTypedFunction returns int(string $stuff, bool, $things, num
$amount) {
return 'This will cause an error.'
}
I want to move the returns clause after the parameter list, but I
couldn't get it to work in the parser:
function x($param) returns y {
return new y
}
Parameters and return values are strict. Int means int (to the type),
etc. For type hinted parameters, null is allowed only if it is the
default value.
Implementations of abstract functions must be compatible both in their
parameter and return types. Mismatched types will cause an error.
Note: The parameter type hinting is complete. The return type hinting
works, but there is a small memory leak which I do not know how to fix.
Besides that it's running perfectly, it's very minor obstacle, I'm just
not familiar enough with C to fix this right now.
Hi!
In general, it'd be very nice to have some definition of the proposed
feature beyond the patch. It would probably answer some of my questions
that follow :)
parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.
What about objects that can be converted to other types (cast_object
handler)?
function myTypedFunction returns int(string $stuff, bool, $things, num
$amount) {
return 'This will cause an error.'
}
What about return "1"? Also I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
Parameters and return values are strict. Int means int (to the type),
Meaning that int would reject 1.0, true and "1"? bool would reject 1 and
0 and null? Ouch, ouch, ouch.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
In general, it'd be very nice to have some definition of the proposed
feature beyond the patch. It would probably answer some of my questions
that follow :)parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.What about objects that can be converted to other types (cast_object
handler)?
Hadn't thought about these, don't see why it couldn't be added though.
function myTypedFunction returns int(string $stuff, bool, $things, num
$amount) {
return 'This will cause an error.'
}What about return "1"? Also I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
We could probably find a way to use the return keyword or another
syntax, I just did it like this for simplicity.
Parameters and return values are strict. Int means int (to the type),
Meaning that int would reject 1.0, true and "1"? bool would reject 1 and
0 and null? Ouch, ouch, ouch.
As it is now, yes, this works just like parameter hints. Could be
changed if decided upon.
I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
I have adapted the patch to reuse the "return" keyword.
Can anyone help me with this?
Here is the current function declaration rule:
T_FUNCTION
{ $1.u.opline_num = CG(zend_lineno); } is_reference T_STRING
optional_function_return_type { zend_do_begin_function_declaration(&$1,
&$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{'
inner_statement_list '}' { zend_do_end_function_declaration(&$1
TSRMLS_CC); }
I want to move "optional_function_return_type" AFTER the parameter list,
but I also need to pass it to zend_do_begin_function_declaration. Is
this even possible?
What I'm trying to acheive is this:
function a($arg1, $arg2) return int {
}
Currently:
function a return int($arg1, $arg2) {
}
Attached is my return type hinting patch. It allows type hinting for
parameters and return values. Int, float, bool, string, num, scalar,
resource, object, array, and class names are supported for both
parameters and return values. Objects with __toString methods are
allowed to pass for scalar and string type hints.function myTypedFunction returns int(string $stuff, bool, $things, num
$amount) {
return 'This will cause an error.'
}I want to move the returns clause after the parameter list, but I
couldn't get it to work in the parser:function x($param) returns y {
return new y
}Parameters and return values are strict. Int means int (to the type),
etc. For type hinted parameters, null is allowed only if it is the
default value.Implementations of abstract functions must be compatible both in their
parameter and return types. Mismatched types will cause an error.Note: The parameter type hinting is complete. The return type hinting
works, but there is a small memory leak which I do not know how to fix.
Besides that it's running perfectly, it's very minor obstacle, I'm just
not familiar enough with C to fix this right now.
Can anyone help me with this?
Here is the current function declaration rule:
T_FUNCTION
{ $1.u.opline_num = CG(zend_lineno); } is_referenceT_STRING
optional_function_return_type { zend_do_begin_function_declaration(&$1,
&$4, 0, $3.op_type, NULL, &$5 TSRMLS_CC); } '(' parameter_list ')' '{'
inner_statement_list '}' { zend_do_end_function_declaration(&$1
TSRMLS_CC); }I want to move "optional_function_return_type" AFTER the parameter list,
but I also need to pass it to zend_do_begin_function_declaration. Is
this even possible?What I'm trying to acheive is this:
function a($arg1, $arg2) return int {
}Currently:
function a return int($arg1, $arg2) {
}
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
--
Alain Williams
Linux 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
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
It gets a little long when you're using classes
abstract protected function return int dostuff() {
}
vs
abstract protected function dostuff() return int {
}
Hi!
Why note the following (which would be more C like):
function return int a($arg1, $arg2) {
}
In C I am familiar with "return" keyword is never used in function
definition.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of other C-style languages before trying to invent something
else? I agree with Stas, "return" and "returns" are not part of a
function definition.
--
Jeremy Privett
C.E.O. & C.S.A.
Omega Vortex Corporation
Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of other C-style languages before trying to invent something
else? I agree with Stas, "return" and "returns" are not part of a
function definition.
I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return).
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a page out of
the book of other C-style languages before trying to invent something
else? I agree with Stas, "return" and "returns" are not part of a
function definition.I don't think it's non-intuitive at all, and even so, it's the most
intuitive we have. This ordering makes more sense to me at first glance (in
the order I would think about things; scope, name, arguments, return).
im not sure the following has been explicitly proposed, but how about
omitting the 'return' keyword and placing the return type hint before the
function identifier
function int a($b, $c) {}
i think that is most congruent with 'typical' of c style languages, no ?
-nathan
> Sam Barrow wrote: > > I figured it out, the syntax is now as follows: > > > > function a($b, $c) returns d { > > } > > > > I'll post an update soon. > > > > > > > > That's certainly a non-intuitive syntax. How about we take a page out of > the book of other C-style languages before trying to invent something > else? I agree with Stas, "return" and "returns" are not part of a > function definition. I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return).
im not sure the following has been explicitly proposed, but how about
omitting the 'return' keyword and placing the return type hint before
the function identifierfunction int a($b, $c) {}
This is, but I don't think this is possible, due to confusion with the
keywords (public, private, static, abstract, etc). Plus this leads to
long strings of keywords.
i think that is most congruent with 'typical' of c style languages,
no ?-nathan
Hello everybody,
I am new here (just reading for last couple of days), so firstly nice
to meet you:)
This discussion seems quite interesting for me and it would be nice
if I can join...
Sam Barrow napisal:
im not sure the following has been explicitly proposed, but how about
omitting the 'return' keyword and placing the return type hint before
the function identifierfunction int a($b, $c) {}
This is, but I don't think this is possible, due to confusion with the
keywords (public, private, static, abstract, etc).
Parser should be able to handle it if the grammar is correct.
"something something2 somethign3 int foo(...)" works fine in some
languages.
LALR parser (Bison is used, isn't it?) is probably the most powerful
parser practically used, and certainly can handle such a set of
keywords correctly - even without "function" keyword (that makes
parsing way easier) - or maybe I have missed some piece of syntax
that might cause the problem (then my apologies)
As there is a person working on converting parser to Lemon, maybe it
would be wise to talk with him (her?), so the grammar is cleaned to
handle it.
Plus this leads to
long strings of keywords.
imho it is shorter - one keyword less. Actually it is also less
confusing for me - maybe because I am using C/C++ and Java a lot
where the syntax is equivalent. And if syntax is strict - i.e.
modifiers first, then returned type - is quite well-readable - name
of the function in the end, returned type just before.
The version with "returns" seems to me like "throws" phrase from e.g.
Java. Btw there was already such a solution in Pascal, but instead of
"returns" colon was used:
function foo(...):integer begin
...
end
Cheers,
Michal Dziemianko
PS. The idea is great anyways - I was always thinking why it is not
implemented:))
> Sam Barrow wrote: > > I figured it out, the syntax is now as follows: > > > > function a($b, $c) returns d { > > } > > > > I'll post an update soon. > > > > > > > > That's certainly a non-intuitive syntax. How about we take a page out of > the book of other C-style languages before trying to invent something > else? I agree with Stas, "return" and "returns" are not part of a > function definition. I don't think it's non-intuitive at all, and even so, it's the most intuitive we have. This ordering makes more sense to me at first glance (in the order I would think about things; scope, name, arguments, return).
im not sure the following has been explicitly proposed, but how about
omitting the 'return' keyword and placing the return type hint before
the function identifierfunction int a($b, $c) {}
This is, but I don't think this is possible, due to confusion with the
keywords (public, private, static, abstract, etc). Plus this leads to
long strings of keywords.
There can be no technical reason why this more adopted and understood syntax
should not be possible. Adding returns as a keyword would completely break
tons of code. Why are the proposals on something that is so consistent
across many languages being changed so obscurely? Why a seperate
non-intuitive syntax.
public function int (string $foo) { return 1; }
Can't we keep the sanity?
[ ... ] Plus this leads to
long strings of keywords.
Are you kidding? strlen('returns int') > strlen('int'); .....
-Chris
I don't know, maybe it does work. But either way I'm not introducing a
new keyword, I changed the patch to reuse the return keyword.
Yes, long strings of keywords:
abstract protected string function dostuff()
On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow sam@sambarrow.com
wrote:> On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow <sam@sambarrow.com> wrote: > On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote: > > Sam Barrow wrote: > > > I figured it out, the syntax is now as follows: > > > > > > function a($b, $c) returns d { > > > } > > > > > > I'll post an update soon. > > > > > > > > > > > > > That's certainly a non-intuitive syntax. How about we take a > page out of > > the book of other C-style languages before trying to invent > something > > else? I agree with Stas, "return" and "returns" are not part > of a > > function definition. > > > I don't think it's non-intuitive at all, and even so, it's the > most intuitive we have. This ordering makes more sense to me > at first glance (in the order I would think about things; > scope, name, arguments, return). > > im not sure the following has been explicitly proposed, but how about > omitting the 'return' keyword and placing the return type hint before > the function identifier > > function int a($b, $c) {} > This is, but I don't think this is possible, due to confusion with the keywords (public, private, static, abstract, etc). Plus this leads to long strings of keywords.
There can be no technical reason why this more adopted and understood
syntax should not be possible. Adding returns as a keyword would
completely break tons of code. Why are the proposals on something that
is so consistent across many languages being changed so obscurely? Why
a seperate non-intuitive syntax.public function int (string $foo) { return 1; }
Can't we keep the sanity?
[ ... ] Plus this leads to long strings of keywords.
Are you kidding? strlen('returns int') > strlen('int'); .....
-Chris
Hello Sam,
I think you misunderstand, let me retype for you.
strlen('abstract protected function string dostuff()') < strlen('abstract
protected function dostuff() return string')
Making your argument on length void, also, maybe we should not base a
language change decision on typing extra characters..
Sorry man, but to me the code below looks so unusual for what it is meant to
represent:
abstract protected function bar($foo) return string {
// code
}
The above, actually kind of makes me think something non-conventional is
going to happen like return string specifies that it will be auto type
casted to a string for me or something. like:
abstract protected function bar($foo) return string {
return $foo;
// is auto magically like: return (string) $foo;
}
vs the below code that tells me function returns a string like in many
popular languages.
abstract protected function string bar($foo) {
return (string) $foo;
}
-Chris
I don't know, maybe it does work. But either way I'm not introducing a
new keyword, I changed the patch to reuse the return keyword.Yes, long strings of keywords:
abstract protected string function dostuff()
On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow sam@sambarrow.com
wrote:> On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow <sam@sambarrow.com> wrote: > On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote: > > Sam Barrow wrote: > > > I figured it out, the syntax is now as follows: > > > > > > function a($b, $c) returns d { > > > } > > > > > > I'll post an update soon. > > > > > > > > > > > > > That's certainly a non-intuitive syntax. How about we take a > page out of > > the book of other C-style languages before trying to invent > something > > else? I agree with Stas, "return" and "returns" are not part > of a > > function definition. > > > I don't think it's non-intuitive at all, and even so, it's the > most intuitive we have. This ordering makes more sense to me > at first glance (in the order I would think about things; > scope, name, arguments, return). > > im not sure the following has been explicitly proposed, but how about > omitting the 'return' keyword and placing the return type hint before > the function identifier > > function int a($b, $c) {} > This is, but I don't think this is possible, due to confusion with the keywords (public, private, static, abstract, etc). Plus this leads to long strings of keywords.
There can be no technical reason why this more adopted and understood
syntax should not be possible. Adding returns as a keyword would
completely break tons of code. Why are the proposals on something that
is so consistent across many languages being changed so obscurely? Why
a seperate non-intuitive syntax.public function int (string $foo) { return 1; }
Can't we keep the sanity?
[ ... ] Plus this leads to long strings of keywords.
Are you kidding? strlen('returns int') > strlen('int'); .....
-Chris
public function int doThing(string $foo) { return 1; }
The above is the best (ie omit 'return' or 'returns').
This also is consistent with C and with the way that the manual is written, eg:
http://www.php.net/manual/en/function.strlen.php
The only argument is the relative ordering of the keywords.
We keep 'function' - since that is the way that the language works.
Things like 'public' we put before 'function' since that is the way that
it works in PHP 5 objects.
So the only thing to decide is where the type goes:
public function int doThing(string $foo) { return 1; }
or:
public int function doThing(string $foo) { return 1; }
I would favour the first one, this is probably also easier to parse, as
following 'function' and before '(' you can have:
- 1 word - which must be the name of the function
- 2 words - the first word is the return type, the second the function name.
If the function returns a reference to something of a particular type, where
does the '&' go:
public function &int doThing(string $foo) { return 1; }
or:
public function int& doThing(string $foo) { return 1; }
I would suggest the second, ie just before the function name.
--
Alain Williams
Linux 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
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
I like the first too, if this can be implemented I think it is a
suitable syntax.
public function int doThing(string $foo) { return 1; }
The above is the best (ie omit 'return' or 'returns').
This also is consistent with C and with the way that the manual is written, eg:
http://www.php.net/manual/en/function.strlen.php
The only argument is the relative ordering of the keywords.
We keep 'function' - since that is the way that the language works.
Things like 'public' we put before 'function' since that is the way that
it works in PHP 5 objects.So the only thing to decide is where the type goes:
public function int doThing(string $foo) { return 1; }
or:
public int function doThing(string $foo) { return 1; }
I would favour the first one, this is probably also easier to parse, as
following 'function' and before '(' you can have:
- 1 word - which must be the name of the function
- 2 words - the first word is the return type, the second the function name.
If the function returns a reference to something of a particular type, where
does the '&' go:public function &int doThing(string $foo) { return 1; }
or:
public function int& doThing(string $foo) { return 1; }
I would suggest the second, ie just before the function name.
--
Alain Williams
Linux 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
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Wouldn't the most consistent way be to omit "function" altogether when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}
public static string foo() {
return $mustBeString;
}
otoh, should there ever be a type "function" (e.g. for anonymous
funcs) down the road, that'd mean trouble ;)
David
Am 26.04.2008 um 01:13 schrieb Alain Williams:
public function int doThing(string $foo) { return 1; }
The above is the best (ie omit 'return' or 'returns').
This also is consistent with C and with the way that the manual is
written, eg:http://www.php.net/manual/en/function.strlen.php
The only argument is the relative ordering of the keywords.
We keep 'function' - since that is the way that the language works.
Things like 'public' we put before 'function' since that is the way
that
it works in PHP 5 objects.So the only thing to decide is where the type goes:
public function int doThing(string $foo) { return 1; }
or:
public int function doThing(string $foo) { return 1; }
I would favour the first one, this is probably also easier to parse,
as
following 'function' and before '(' you can have:
- 1 word - which must be the name of the function
- 2 words - the first word is the return type, the second the
function name.If the function returns a reference to something of a particular
type, where
does the '&' go:public function &int doThing(string $foo) { return 1; }
or:
public function int& doThing(string $foo) { return 1; }
I would suggest the second, ie just before the function name.
--
Alain Williams
Linux 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
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h
Wouldn't the most consistent way be to omit "function" altogether when
using a return type hint?public static function zomg() {
return $somethingArbitrary;
}public static string foo() {
return $mustBeString;
}
i think leaving 'function' in there makes sense because thats the way php
currently works.
otoh, should there ever be a type "function" (e.g. for anonymous funcs) down
the road, that'd mean trouble ;)
wow; good point! maybe if anonymous functions are ever supported the type
could be capitalized as in 'Function'
public function Function doStuff() {
return function() {}
}
-nathan
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
On Sat, Apr 26, 2008 at 2:06 PM, David Zülke dz@bitxtender.com
wrote:Wouldn't the most consistent way be to omit "function" altogether
when
using a return type hint?public static function zomg() {
return $somethingArbitrary;
}public static string foo() {
return $mustBeString;
}i think leaving 'function' in there makes sense because thats the
way php
currently works.
Well that was my point. Functions without return type hints use
"function", to indicate that they are generic in this respect, and
functions/methods with a type hint omit it to signal the difference.
Having both would be redundant. But then...:
otoh, should there ever be a type "function" (e.g. for anonymous
funcs) down
the road, that'd mean trouble ;)wow; good point! maybe if anonymous functions are ever supported
the type
could be capitalized as in 'Function'public function Function doStuff() {
return function() {}
}
Absolutely not. Right now, all PHP native types are lowercase. Can't
see why anon functions should be different.
Actually, both ways have problems:
public function gimmeThat() {
return function() { echo 'yay'; }
}
is ambiguous if return type hints require omitting "function", and
public function function gimmeThat() {
...
}
is just plain ugly.
So maybe anon funcs should have a different type name :p
David
cough lambda cough
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
Wouldn't the most consistent way be to omit "function" altogether when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}public static string foo() {
return $mustBeString;
}i think leaving 'function' in there makes sense because thats the way
php
currently works.Well that was my point. Functions without return type hints use
"function", to indicate that they are generic in this respect, and
functions/methods with a type hint omit it to signal the difference. Having
both would be redundant. But then...:otoh, should there ever be a type "function" (e.g. for anonymous funcs)
down
the road, that'd mean trouble ;)wow; good point! maybe if anonymous functions are ever supported the
type
could be capitalized as in 'Function'public function Function doStuff() {
return function() {}
}Absolutely not. Right now, all PHP native types are lowercase. Can't see
why anon functions should be different.Actually, both ways have problems:
public function gimmeThat() {
return function() { echo 'yay'; }
}is ambiguous if return type hints require omitting "function", and
public function function gimmeThat() {
...
}is just plain ugly.
So maybe anon funcs should have a different type name :p
David
But anonymous functions and lambda expressions are not the same thing...
David
Am 27.04.2008 um 02:11 schrieb Chris Stockton:
cough lambda cough
On Sat, Apr 26, 2008 at 4:26 PM, David Zülke dz@bitxtender.com
wrote:
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:On Sat, Apr 26, 2008 at 2:06 PM, David Zülke dz@bitxtender.com
wrote:Wouldn't the most consistent way be to omit "function" altogether when
using a return type hint?public static function zomg() {
return $somethingArbitrary;
}public static string foo() {
return $mustBeString;
}i think leaving 'function' in there makes sense because thats the
way php
currently works.Well that was my point. Functions without return type hints use
"function", to indicate that they are generic in this respect, and
functions/methods with a type hint omit it to signal the difference.
Having both would be redundant. But then...:otoh, should there ever be a type "function" (e.g. for anonymous
funcs) down
the road, that'd mean trouble ;)wow; good point! maybe if anonymous functions are ever supported
the type
could be capitalized as in 'Function'public function Function doStuff() {
return function() {}
}Absolutely not. Right now, all PHP native types are lowercase. Can't
see why anon functions should be different.Actually, both ways have problems:
public function gimmeThat() {
return function() { echo 'yay'; }
}is ambiguous if return type hints require omitting "function", and
public function function gimmeThat() {
...
}is just plain ugly.
So maybe anon funcs should have a different type name :p
David
Anonymous functions as you know them today come from lambda calculus which
was created before computers were even made. Generally it is agreed anon
func == labmda can be used interchangeably.
Most developers will understand what:
public function lambda sowat () { return function OR lambda, whatever () { }
}
Seems more natural then whatever nightmare people could think of, like
public function Function or public function ANONFUNCLOL...
The thing that I hate about that idea is not a reserved word, any there is
surely plenty of people with functions named them. Perhaps that detail can
be worked out in the grammar without breaking bc.
-Chris
But anonymous functions and lambda expressions are not the same thing...
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
there
Agree?
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
thereAgree?
Again, what's about the well written RFC and patch from RFC? Have you
contacted him and/or tried to get things done there instead of
duplicating the discussions, the work and the code?
Thanks for your work,
Cheers,
Mine uses less code to accomplish the same thing, doesn't introduce new
tokens, and has an easier syntax. I'm still working on it, but I can
give an update in a couple days. I just wanted to see what people
thought about the implementation aspect of it.
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
thereAgree?
Again, what's about the well written RFC and patch from RFC? Have you
contacted him and/or tried to get things done there instead of
duplicating the discussions, the work and the code?Thanks for your work,
Cheers,
Mine uses less code to accomplish the same thing, doesn't introduce new
tokens, and has an easier syntax.
Ok, sorry to have tried to get this feature in. I do think that going
down the way you choosed right now is the best way to forget this
feature forever.
I'm still working on it, but I can
give an update in a couple days. I just wanted to see what people
thought about the implementation aspect of it.
The RFC system was proposed exactly for one reason: to avoid dozen pf
repetitive discussions about the same topic raised every twp weeks on
internals. But you seem to completely miss it.
Sorry to have interfered in this thread,
Cheers,
As I've pointed out,
public array x()
will become ambiguous once we introduce a type "function", which is
not unlikely at this point
David
Am 29.04.2008 um 17:22 schrieb Sam Barrow:
Well in summation I think this is something that should be
implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it
out
thereAgree?
As I've pointed out,
public array x()
will become ambiguous once we introduce a type "function", which is
not unlikely at this point
That's what I thought, that's why I said number 1 is the most likely.
David
Am 29.04.2008 um 17:22 schrieb Sam Barrow:
Well in summation I think this is something that should be
implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it
out
thereAgree?
Hi!
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.
I think we had plenty of arguments against it last time it was
discussed. You could see it here for example:
http://marc.info/?l=php-internals&m=118478789527042&w=2
But I can repeat.
Return types are useful in statically compiled languages, since they
enable static type control. Since PHP has no static type control, return
type is useless for the function client - the fact that function returns
type X itself can be found in the documentation (where it belongs) -
that includes PHPDoc for the smarter IDEs out there - but code-wise
there's no useful action I can take using this information that I can't
take using just what function actually returns and be safer.
Return type definition can prohibit function from returning different
types, however here we have two problems. First is that function
definition and code is usually written by the same person in the same
(very small) context, and this person has to be somewhat absent-minded
to forget what function returns from definition to return a dozen lines
below. Supporting such absent-mindedness with language constructs
doesn't appear appropriate. Second is that only action return type
definition could take in this case is break the application in runtime,
which would be of little help to our absent-minded function writer and
especially to its client.
But even worse, since on the client side you have no way to enforce this
restriction, you can't even rely on it in any context - what if the
absent-minded function writer forgot to put the type restriction? If the
type was important for you, you'd have to check it anyway, since you
have no way to enforce the restriction on the client side! Since your
enforcement on one side and your usage of the data is on the other, the
enforcement is unreliable and thus useless.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Sam Barrow wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
thereAgree?
How about using the ActionScript syntax?
public function x():array { ... }
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
And bad idea about making a return type "function" - looks very useless and
will not be used a lot. Work with objects with methods returning an object
of some kind, then you can do
$object->method()->method2()->method3();
P.S. I think this thread should be merged with function param type hinting
because they come together and should be implemented together,
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}C/C++ like, easy to understand
And bad idea about making a return type "function" - looks very
useless and will not be used a lot. Work with objects with methods
returning an object of some kind, then you can do
Function is a reserved keyword in PHP anyway, it would cause problems in
numerous places if it was used as a type.
$object->method()->method2()->method3();
P.S. I think this thread should be merged with function param type
hinting because they come together and should be implemented together,
Well this is two parts, class/array hinting and scalar hinting. Class
and array hinting is already implemented, so for now I'm just pushing
for that in return types.
Sam Barrow wrote:
Well in summation I think this is something that should be implemented,
I don't see any arguments against implementing this atleast for arrays
and classes, like we already have for function parameters.The only thing left would be to decide on the syntax
public array function x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
thereAgree?
How about using the ActionScript syntax?
public function x():array { ... }
I like that, but in that case we might as well leave out the colon.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Sam Barrow wrote:
Attached is my return type hinting patch. [snip]
I have a question independent of syntax/design-concerns: does this patch
utilize typed returns to afford performance benefits to userland code
that use it?
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]