[PHP-INTERNALS] Return type hinting patch

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 :)
What about objects that can be converted to other types (cast_object
handler)?
What about return "1"? Also I notice it introduces new keyword -
returns. Is it necessary? Each new keyword means broken code.
Meaning that int would reject 1.0, true and "1"? bool would reject 1 and
0 and null? Ouch, ouch, ouch.

Hadn't thought about these, don't see why it couldn't be added though.
We could probably find a way to use the return keyword or another
syntax, I just did it like this for simplicity.
As it is now, yes, this works just like parameter hints. Could be
changed if decided upon.

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) {
}

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!
In C I am familiar with "return" keyword is never used in function
definition.

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

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?


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

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

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.

I like the first too, if this can be implemented I think it is a
suitable syntax.

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:

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

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

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


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*

But anonymous functions and lambda expressions are not the same thing...


David



Am 27.04.2008 um 02:11 schrieb Chris Stockton:

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

That would be nice, but the scoping of variables in PHP doesn't seem to
make that nice, the code below results in '' Undefined variable: aa ''
if I take the 'global' statement out, if I leave it in the echo in b()
shows it as the empty string.

Getting this right would be nice as it would allow (what has been explained
to me at any rate) functional programming if a() returns an anonymous b().
The stuff below works in perl and python.


function a($aa) {
echo "a called aa=$aa\n";
function b() {
global $aa;
echo "in b aa=$aa\n";
}

b();
}

a('this is aa');

Because aa is not global in your example. Variables are either global
or function-scoped in PHP. There is no such thing as a context or
parent scope which is what you are looking for here.

The suggestion when last this was discussed was to introduce a
keyword "lexical" that would mean "pull this variable in from the lexical
parent of this function, with the same semantics as pulling in a global
variable". Aside from the introduction of another reserved word, it seemed
like a well-received idea and a good solution.

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?

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.

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

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

How about using the ActionScript syntax?

public function x():array { ... }

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,

+1 -- least confusion to most people.

Taking it a bit further, if the function returns a reference (eg to its argument):

function int &myfunction(int &$param)

Alternative could be:
function &int myfunction(int &$param)

But I think that the first form is better.
Sam has done much work on param type hinting, we should thank him for his hard work.

I like this better, I think this would just be a matter of ordering
arguments in the parser.

From one whose job it is to daily *teach* PHP. The first form is very
much better.

And:

Suggestions to omit the word "function" altogether will be a nightmare
from a teaching point of view. Convenience for experienced programmers
should not come at the cost of unnecessary heightening of the threshold
for newcomers.

And:

Once again, the main language besides PHP for most web developers is
JavaScript. Actionscript has been mentioned. The future of Actionscript
is ES 4. And from what I've recently read JavaScript is now the most
language used of all. Anyway, here's from Brendan E:

function f(a : int, b : String, c : Object) : RetType
{
// arguments are guaranteed to match types
// return value must convert to or match RetType
}

Personally I believe that the colon adds readability. *If* return type
hints are accepted I think this syntax is the best. (I do *not* think
PHP should add anything else from ES 4 when it comes to types.)


Lars Gunther

+1. We also don't want to break existing code or have two ways of doing
the same thing (that is perl's job :-) )
Nice in some ways, except that it is different from the way that type hinting
works in PHP5 classes - again: keep to one way of doing things.

': RetType' might be possible, but it is very different from where type hints
are given currently in PHP.

Stick with:

function int &myfunction(int &$param)

Yes, on second thought I agree. "Keep to one way of doing things" is
definitely sound advice from a teaching POV.


Lars Gunther

Function is a reserved keyword in PHP anyway, it would cause problems in
numerous places if it was used as a type.
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.

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

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?