My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting
Notable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs - The patch includes basic opcache and reflection support. It also has
phpt tests. - Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before voting. - This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.
As a friendly reminder, everyone on this list is interested in developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!
Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara - For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehinting
As a PHP user, this is great. Finally we can stop using silly docblock comments to denote return types!
+1 from me!
- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.
Well, I think that that should be added here also your future work of 'void'.
So, add: int, float, numeric (int or float), string, bool, void.
Sorry.
--
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
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before voting.- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.
This will come in very handy over at the PHP-FIG, as we can specify
return types for interface methods instead of just type hinting parameters.
All for it. This has been done in a way that is fully BC, resolves any
of the previous complaints, offers useful functionality, does not bite
off more than it can chew, ignores the whole "nullable AND specific
type" black hole and gets the job done.
Best of luck with this one Levi.
Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.
This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:
class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}
With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}
Lazare INEPOLOGLOU
Ingénieur Logiciel
Nice proposal.
FWIW on the use issue I much prefer the first alternative:
function ($foo): Bar use ($quux) {}
function ($foo) use ($quux): Bar {}
Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this
notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in
developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I
gleaned
valuable knowledge from your proposals and the discussion around them.This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}Lazare INEPOLOGLOU
Ingénieur Logiciel
--
Pete Boere
Web Developer
From: Pete Boere [mailto:pete@the-echoplex.net]
Nice proposal.
FWIW on the
useissue I much prefer the first alternative:function ($foo): Bar use ($quux) {}
function ($foo) use ($quux): Bar {}
I like the idea and the FRC, too!
But referring to the use issue: Just from reading the first alternative
sounds like "Bar uses xy", which sounds strange to me. I'd prefer the
second alternative.
On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou linepogl@gmail.comwrote:
Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}
As the patch currently stands you can use the type-hint 'self'.
On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou
linepogl@gmail.comwrote:Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}As the patch currently stands you can use the type-hint 'self'.
How will this patch work with LSB?
On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou
linepogl@gmail.comwrote:Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also
has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this
notably
excludes type-hints for scalars. Supporting scalar type declarations
is
outside the scope of this RFC; if you are interested in supporting
scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in
developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov
and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I
gleaned
valuable knowledge from your proposals and the discussion around them.This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}As the patch currently stands you can use the type-hint 'self'.
How will this patch work with LSB?
Late static binding is not a feature I am very familiar with. After some
investigation it appears that we curently don't support late static binding
on parameters; this means that I will not support late static binding on
returns either. I want to keep the impact as small as possible.
On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou
linepogl@gmail.comwrote:Hello,
2014-04-24 17:59 GMT+02:00 Levi Morrison levim@php.net:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also
has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this
notably
excludes type-hints for scalars. Supporting scalar type declarations
is
outside the scope of this RFC; if you are interested in supporting
scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in
developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov
and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I
gleaned
valuable knowledge from your proposals and the discussion around them.This is a nice and well thought proposal.
I would like to suggest the addition of the "self" and "static" pseudo
types. Most IDEs support this through @return syntax:class Foo {
/** @return static */
public function SetBar( $bar ) {
// ...
return $this;
}
}With the new syntax, the above could be transformed into this:
class Foo {
public function SetBar( $bar ) : static {
// ...
return $this;
}
}As the patch currently stands you can use the type-hint 'self'.
How will this patch work with LSB?
Late static binding is not a feature I am very familiar with. After some
investigation it appears that we curently don't support late static binding
on parameters; this means that I will not support late static binding on
returns either. I want to keep the impact as small as possible.
Yep, this RFC is light and that's why it's nice :-)
I'm all +1 with it.
Keep the impact low as well as adding a nice, more-and-more-expected
feature, which keeps BC.
What should we ask for next ? :-)
You have my support.
Julien
Am 28.04.2014 11:23, schrieb Julien Pauli:
You have my support.
Mine as well. I am for using the same syntax that Hack already has.
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before voting.- This RFC does not add, modify, or remove keywords at all; this notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I gleaned
valuable knowledge from your proposals and the discussion around them.
Simple, targeted, focused, I like. I very much like the NULL handling,
as it means as a caller I have to do less work.
One bit strikes me as odd. In the invalid examples, you have this example:
function foo(): array {
yield [];
}
which generates this error:
Fatal error: Generators may only yield objects, array is not a valid
type in %s on line %d
Except Generators can totally yield arrays currently:
function foo() {
yield [];
}
foreach (foo() as $x) print_r($x) . PHP_EOL;
The above works perfectly on 5.5.10, where I just tested it.
So what's with that error condition? Clearly from the RFC we can
specify array as a return type, so I don't know why it calls out
generators as specially limited.
As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the
generator. That seems like a likely source of confusion, as I would, as
a developer, expect to be specifying the type that gets returned from
iteration, not from construction, so that my foreach loop (or similar)
can rely on the type being returned.
I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.
As far as the order of keywords in a closure, what order does Hack use?
The rest of the syntax seems based on it, so it seems sensible to
follow suit. (I couldn't find that information from 60 seconds on
hacklang.org, but it may be there.)
--Larry Garfield
(Apparently only replied to Sebastian while on mobile :)
I know this RFC does not address multiple return types on purpose.
But supposing it's implemented in its current form, what would be a
possible syntax for multiple/mixed return types?
Namely for the usual suspects of string|null, array|null, Class|bool,
or ClassA|ClassB|bool, etc...
Something along those lines.
Cheers
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this
notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I
gleaned
valuable knowledge from your proposals and the discussion around them.Simple, targeted, focused, I like. I very much like the
NULLhandling, as
it means as a caller I have to do less work.One bit strikes me as odd. In the invalid examples, you have this example:
function foo(): array {
yield [];
}which generates this error:
Fatal error: Generators may only yield objects, array is not a valid type in
%s on line %dExcept Generators can totally yield arrays currently:
function foo() {
yield [];
}
foreach (foo() as $x) print_r($x) . PHP_EOL;The above works perfectly on 5.5.10, where I just tested it.
So what's with that error condition? Clearly from the RFC we can specify
array as a return type, so I don't know why it calls out generators as
specially limited.As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not from
construction, so that my foreach loop (or similar) can rely on the type
being returned.I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.As far as the order of keywords in a closure, what order does Hack use? The
rest of the syntax seems based on it, so it seems sensible to follow suit.
(I couldn't find that information from 60 seconds on hacklang.org, but it
may be there.)--Larry Garfield
On Mon, Apr 28, 2014 at 12:16 PM, Larry Garfield larry@garfieldtech.comwrote:
My dear Internals friends,
I have spent the last month drafting an RFC that allows return types:
https://wiki.php.net/rfc/returntypehintingNotable items:
- Differences from past RFCs are summarized in the RFC:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs- The patch includes basic opcache and reflection support. It also has
phpt tests.- Informal performance tests indicate that the patch did not fubar
performance; if desired a more detailed test can be conducted before
voting.- This RFC does not add, modify, or remove keywords at all; this
notably
excludes type-hints for scalars. Supporting scalar type declarations is
outside the scope of this RFC; if you are interested in supporting scalar
type declarations please discuss it elsewhere.As a friendly reminder, everyone on this list is interested in developing
a
better PHP and the definitions of 'better' vary from person to person.
Please be civil and constructive while discussing this RFC. Thank you!Some thanks, regardless if the RFC is accepted:
- For providing a patch: Joe Watkins.
- For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov and
Anthony Ferrara- For previous RFCs on this topic: Felipe Pena and Will Fitch. I
gleaned
valuable knowledge from your proposals and the discussion around them.Simple, targeted, focused, I like. I very much like the
NULLhandling, as
it means as a caller I have to do less work.
Thank you.
One bit strikes me as odd. In the invalid examples, you have this example:
function foo(): array {
yield [];
}which generates this error:
Fatal error: Generators may only yield objects, array is not a valid type
in %s on line %dExcept Generators can totally yield arrays currently:
function foo() {
yield [];
}
foreach (foo() as $x) print_r($x) . PHP_EOL;The above works perfectly on 5.5.10, where I just tested it.
So what's with that error condition? Clearly from the RFC we can specify
array as a return type, so I don't know why it calls out generators as
specially limited.As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not
from construction, so that my foreach loop (or similar) can rely on the
type being returned.
The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.
I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.
Special casing a generator's return type would be an inconsistency in the
design. If you var_dump() something that returns generator it tells you it
is a generator; this should match the type of the return value and anything
else is unexpected. As an example, using a generator to fulfill an Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in all,
special casing generators doesn't make sense.
As far as the order of keywords in a closure, what order does Hack use?
The rest of the syntax seems based on it, so it seems sensible to follow
suit. (I couldn't find that information from 60 seconds on hacklang.org,
but it may be there.)
At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:
- use statements are basically parameters at construction time instead of
runtime - putting the return type before the use statement looks really ugly
I will attempt to contact the HHVM team (perhaps SaraG) to see if there was
a technical reason for it.
As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the generator.
That seems like a likely source of confusion, as I would, as a developer,
expect to be specifying the type that gets returned from iteration, not
from construction, so that my foreach loop (or similar) can rely on the
type being returned.The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.
So I suppose technically we should say that a generator must always
return a Traversable?
I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.Special casing a generator's return type would be an inconsistency in the
design. If youvar_dump()something that returns generator it tells you it
is a generator; this should match the type of the return value and anything
else is unexpected. As an example, using a generator to fulfill an Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in all,
special casing generators doesn't make sense.
That makes sense from an engine point of view, certainly. From a user
POV, I can still see it being the source of much confusion. I confess
I've barely used generators so far (PHP 5.5 still having very small
market penetration), but it feels natural to mentally align return type
/ return keyword and return type / yield keyword. It also means I have
no way of declaring that a generator will always return items of type X,
which seems like a valid thing to do.
As far as the order of keywords in a closure, what order does Hack use?
The rest of the syntax seems based on it, so it seems sensible to follow
suit. (I couldn't find that information from 60 seconds on hacklang.org,
but it may be there.)At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:
- use statements are basically parameters at construction time instead of
runtime- putting the return type before the use statement looks really ugly
I will attempt to contact the HHVM team (perhaps SaraG) to see if there was
a technical reason for it.
I would agree, and look forward to seeing their reasoning.
--Larry Garfield
On Mon, Apr 28, 2014 at 3:43 PM, Larry Garfield larry@garfieldtech.comwrote:
As I write that I suspect it's because generators actually "return" an
interator object, and so the return type of the generator is being
interpreted relative to the construction, not iteration, of the
generator.
That seems like a likely source of confusion, as I would, as a
developer,
expect to be specifying the type that gets returned from iteration, not
from construction, so that my foreach loop (or similar) can rely on the
type being returned.The type hint is purposefully not the type of the value returned; a
generator always returns a generator. I will clarify this in the RFC and
maybe adjust the wording in the error message as well to better indicate
this.So I suppose technically we should say that a generator must always return
a Traversable?
Not quite: a generator always returns a Generator (this is an actual
object); so it can fulfill Generator, Iterator and Traversable.
I think this part warrants further consideration. The rest of the RFC I
fully look forward to using.
Special casing a generator's return type would be an inconsistency in the
design. If youvar_dump()something that returns generator it tells you it
is a generator; this should match the type of the return value and
anything
else is unexpected. As an example, using a generator to fulfill an
Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in
all,
special casing generators doesn't make sense.That makes sense from an engine point of view, certainly. From a user
POV, I can still see it being the source of much confusion. I confess I've
barely used generators so far (PHP 5.5 still having very small market
penetration), but it feels natural to mentally align return type / return
keyword and return type / yield keyword. It also means I have no way of
declaring that a generator will always return items of type X, which seems
like a valid thing to do.
Agreed; however I would rather have all kinds of Iterators and collection
like object be able to type their values too. This would obviously fall
outside of this RFC so I have specifically left this possibility open
without directing its future too much.
So I suppose technically we should say that a generator must always return
a Traversable?
Not quite: a generator always returns a Generator (this is an actual
object); so it can fulfill Generator, Iterator and Traversable.
A recent patch update actually says this in very clear terms; the RFC
simply fell a tad bit behind to reflect the improvement. It has now been
updated.
Special casing a generator's return type would be an inconsistency in the
design. If youvar_dump()something that returns generator it tells you it
is a generator; this should match the type of the return value and
anything
else is unexpected. As an example, using a generator to fulfill an
Iterator
return type should succeed; special casing the Generator would complicate
the code to achieve this. Special casing the generator would also infringe
on other future ideas, such as adding generics to the language. All in
all,
special casing generators doesn't make sense.That makes sense from an engine point of view, certainly. From a user
POV, I can still see it being the source of much confusion. I confess I've
barely used generators so far (PHP 5.5 still having very small market
penetration), but it feels natural to mentally align return type / return
keyword and return type / yield keyword. It also means I have no way of
declaring that a generator will always return items of type X, which seems
like a valid thing to do.Agreed; however I would rather have all kinds of Iterators and collection
like object be able to type their values too. This would obviously fall
outside of this RFC so I have specifically left this possibility open
without directing its future too much.
In other words, "let's punt on that until we figure out generics". With
the new error message in the RFC I can work with that. Thanks.
--Larry Garfield
As far as the order of keywords in a closure, what order does Hack use?
The rest of the syntax seems based on it, so it seems sensible to
follow
suit. (I couldn't find that information from 60 seconds on hacklang.org
,
but it may be there.)At least in the 2.4 branch of HHVM (which I have installed) they put it
before the use statement. Now that I have thought about this more, this is
a poor decision:
- use statements are basically parameters at construction time instead
of
runtime- putting the return type before the use statement looks really ugly
I will attempt to contact the HHVM team (perhaps SaraG) to see if there
was
a technical reason for it.I would agree, and look forward to seeing their reasoning.
HHVM puts the return type before the use case because:
- A user is already familiar with function(): Foo
- A use statement is not really part of the function signature (during
inheritance and such)
Additionally, it is common to write closures using their shorthand
notation: ==> (see http://docs.hhvm.com/manual/en/hack.lambda.php)
I would counter:
- Use statements are special parameters (similar to constructor
arguments) and that putting it after the use statement makes more sense - Putting it after use statements is less ugly.
- Putting it before the use statement is a bit confusing; consider this
Hack declaration:
$i = 0;
$inc = function(): Iterator<int> use(&$i) {//...
It looks like the Iterator<int> is somehow using $i.
What does this list think?
I will attempt to contact the HHVM team (perhaps SaraG) to see if there
was
a technical reason for it.I would agree, and look forward to seeing their reasoning.
HHVM puts the return type before the use case because:
- A user is already familiar with function(): Foo
- A use statement is not really part of the function signature (during
inheritance and such)Additionally, it is common to write closures using their shorthand
notation: ==> (see http://docs.hhvm.com/manual/en/hack.lambda.php)I would counter:
- Use statements are special parameters (similar to constructor
arguments) and that putting it after the use statement makes more sense- Putting it after use statements is less ugly.
- Putting it before the use statement is a bit confusing; consider this
Hack declaration:
$i = 0;
$inc = function(): Iterator<int> use(&$i) {//...
It looks like the Iterator<int> is somehow using $i.What does this list think?
Honestly I don't much care for the compact lambda syntax in Hack as I
like that PHP is explicit on variable capture. (Javascript isn't, and
it's a common source of errors; see the "never do this" comment on the
link above.)
I subjectively like the return at the very end, too. The return is the
"last" thing that matters, so it comes at the end. Too, it clusters all
of the inputs together (parameters and closures) followed by the output
(return).
--Larry Garfield
Hi,
Why using an additional ":" symbol for the return type? what about
considering this:
function foo() string { }
and for closure:
$bar = 1;
$foo = function() use ($bar) string {
};
I think removing ":" symbol is cleaner.
On Tue, Apr 29, 2014 at 11:10 PM, Larry Garfield larry@garfieldtech.comwrote:
I will attempt to contact the HHVM team (perhaps SaraG) to see if there
was
a technical reason for it.I would agree, and look forward to seeing their reasoning.
HHVM puts the return type before the use case because:
- A user is already familiar with function(): Foo
- A use statement is not really part of the function signature (during
inheritance and such)Additionally, it is common to write closures using their shorthand
notation: ==> (see http://docs.hhvm.com/manual/en/hack.lambda.php)I would counter:
- Use statements are special parameters (similar to constructor
arguments) and that putting it after the use statement makes more sense- Putting it after use statements is less ugly.
- Putting it before the use statement is a bit confusing; consider this
Hack declaration:
$i = 0;
$inc = function(): Iterator<int> use(&$i) {//...
It looks like the Iterator<int> is somehow using $i.What does this list think?
Honestly I don't much care for the compact lambda syntax in Hack as I like
<bikeshed>
that PHP is explicit on variable capture. (Javascript isn't, and it's a
common source of errors; see the "never do this" comment on the link above.)I subjectively like the return at the very end, too. The return is the
</bikeshed>
"last" thing that matters, so it comes at the end. Too, it clusters all of
the inputs together (parameters and closures) followed by the output
(return).--Larry Garfield
--
--
Best Regards,
Yo-An Lin
Why using an additional ":" symbol for the return type? what about
considering this:function foo() string { }
and for closure:
$bar = 1;
$foo = function() use ($bar) string {};
I think removing ":" symbol is cleaner.
Presumably it’s because TypeScript, ActionScript and Hack already use the function foo() : type form, so it’s a familiar syntax. However, Go uses the func foobar() type form, so there’s also precedent for that one. Considering the audience of PHP, TypeScript, ActionScript and Hack are probably more familiar than Go.
Maybe there’s a technical reason for it, though.
Andrea Faulds
http://ajf.me/
Hi,
Why using an additional ":" symbol for the return type? what about
considering this:function foo() string { }
and for closure:
$bar = 1;
$foo = function() use ($bar) string {};
I think removing ":" symbol is cleaner.
Your point is valid, certainly. We could omit it. Here are two minor things
to think about:
- Syntax is a visual indicator.
- Compatibility and familiarity to similar languages.
Syntax can be used to visually indicate things to the programmer. For
instance, the () in a conditional statement is not strictly necessary
from a language design perceptive and Go chose to omit them. Valid Go:
if $var === $null {
}
In our case the colon indicates that you are declaring a return type and
you can read it aloud as "returns". While not strictly necessary it does
give a visual indicator of what is going on.
function date_diff(DateTime $a, DateTime $b) : DateInterval;
The above function can be read aloud as:
"Function date_diff takes DateTime a and DateTime b and returns
DateInterval"
The colon indicates 'returns'. You can infer this from the context, sure;
again I did say this was a minor thing.
In the case of the colon I value being compatible with Hack more than the
small gain of omitting the colon.
Valid Go:
if $var === $null {
}
(I wasn't perfectly clear; if PHP omitted the parenthesis like Go then it
would look like it does above)
Hi,
Why using an additional ":" symbol for the return type? what about
considering this:
snip
In the case of the colon I value being compatible with Hack more than the
small gain of omitting the colon.
^^ What Levi said. Colon vs. no colon is an easily bikesheddable
discussion, and I'm happy to answer that with "follow HACK's lead to
avoid confusion/incompatibility later".
--Larry Garfield
Oh, so HACK picked this syntax. agree for avoiding compatibility.
On Thu, May 8, 2014 at 6:35 AM, Larry Garfield larry@garfieldtech.comwrote:
On Wed, May 7, 2014 at 11:02 AM, Lin Yo-An cornelius.howl@gmail.com
wrote:Hi,
Why using an additional ":" symbol for the return type? what about
considering this:snip
In the case of the colon I value being compatible with Hack more than the
small gain of omitting the colon.
^^ What Levi said. Colon vs. no colon is an easily bikesheddable
discussion, and I'm happy to answer that with "follow HACK's lead to avoid
confusion/incompatibility later".--Larry Garfield
--
--
Best Regards,
Yo-An Lin
Oh, so HACK picked this syntax. agree for avoiding compatibility.
You meant “incompatibility” right, unless you want to spite Facebook?
--
Andrea Faulds
http://ajf.me/