Heya,
Its seems to me that more and more RFC are proposed to augment PHP's syntax with some form of additional type hints.
The following RFC proposes to add a type hint for the return type of a function/method:
https://wiki.php.net/rfc/returntypehinting
It adds the type hint on the right hand side of the function (of the identifier). In contrast to parameters where the
type hint is placed on the left hand side of the identifier.
Mixing both, having some types on the left and others on the right, seems like another inconsistency in the language
design to me.
I think now is the time where we should decide what convention we want to stick to in the future (either left or right).
PHP 7 is the perfect time to make a change. I do not want to take sides because I am not yet sure what I prefer but
following some examples for both conventions:
function foo($a : Foo, $b : array) : void {} // types on the right
function void foo(Foo $a, array $b){} // types on the left
Assuming PHP will introduce type hints for properties at some point
class A{
private $f : Foo; //types on the right
private Foo $f; //types on the left
}
Assuming PHP will introduce type hints for variables at some point
$a : int = 1; //types on the right
int $a = 1; // types on the left
Assuming PHP will introduce generics and typed arrays at some point.
function foo<T>($a : T, $b : array<Bar>, $c : Foo[]) : callable<T, Car> {} // types on the right
function callable<T, Car> foo<T>(T $a, array<Bar> $b, Foo[] $c){} // types on the left
Thoughts?
Cheers,
Robert
It adds the type hint on the right hand side of the function (of the identifier). In contrast to parameters where the
type hint is placed on the left hand side of the identifier.
Mixing both, having some types on the left and others on the right, seems like another inconsistency in the language
design to me.
These inconsistencies exist for two reasons:
- Opposition to doing it the other way
- Hack already doing it this way
I don’t think function void foo(); will happen, since that’s been previously rejected as it breaks gripping for “function foo”. Similarly, I don’t think public $foo: Foo; will happen, given Hack does it as public Foo $foo;.
PHP doesn’t need more inconsistency, sure, but we must be practical here. It is bad if PHP and Hack have the same feature with different syntax, it will cause developer confusion and further segment the communities. It is bad if we don’t get return type hinting because the “consistent” syntax would upset some people.
--
Andrea Faulds
http://ajf.me/
Hi!
PHP doesn’t need more inconsistency, sure, but we must be practical
here. It is bad if PHP and Hack have the same feature with different
syntax, it will cause developer confusion and further segment the
communities.
Given that Hack is a different language, which was designed AFAIK with
little input from PHP community, I don't see how there would be any
confusion - it's like saying PHP and Perl or PHP and Java having
different syntaxes leads to segmenting the communities. In fact, there
are two different communities - though, of course, people can belong to
both - and two different languages. I do not think Hack syntax should
have much weight in decisions about what syntax to choose in PHP - it's
a different language, even though it has many similarities.
Hi!
PHP doesn’t need more inconsistency, sure, but we must be practical
here. It is bad if PHP and Hack have the same feature with different
syntax, it will cause developer confusion and further segment the
communities.Given that Hack is a different language, which was designed AFAIK with
little input from PHP community, I don't see how there would be any
confusion - it's like saying PHP and Perl or PHP and Java having
different syntaxes leads to segmenting the communities.
This is an unfair comparison. Hack is a compatible superset of PHP, much like TypeScript is a compatible superset of JavaScript.
In fact, there
are two different communities - though, of course, people can belong to
both - and two different languages. I do not think Hack syntax should
have much weight in decisions about what syntax to choose in PHP - it's
a different language, even though it has many similarities.
I’d rather there be less divergence between Hack and PHP, to limit the damage that it causes to the community.
--
Andrea Faulds
http://ajf.me/
Hi!
This is an unfair comparison. Hack is a compatible superset of PHP,
much like TypeScript is a compatible superset of JavaScript.
So? PHP once borrowed Perl syntax, and Java syntax, and so on. Hack
borrowed PHP syntax, and that's great. But that doesn't mean what they
do in their own language should constraint what we do in PHP.
I’d rather there be less divergence between Hack and PHP, to limit
the damage that it causes to the community.
I don't see any damage to the community. How PHP not matching other
language's syntax does any damage to the community? What kind of damage
and where this damage comes from? Are we damaged because PHP arrays and
Perl arrays have different syntax, despite obvious Perl roots in PHP?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
This is an unfair comparison. Hack is a compatible superset of PHP,
much like TypeScript is a compatible superset of JavaScript.So? PHP once borrowed Perl syntax, and Java syntax, and so on. Hack
borrowed PHP syntax, and that's great. But that doesn't mean what they
do in their own language should constraint what we do in PHP.
Again, an unfair comparison. Hack isn’t intended to be a completely separate language. It’s supposed to be an augmented PHP, which is compatible with PHP. PHP code can use Hack code (in HHVM, anyway) and Hack code can use PHP code. Hack is a superset of PHP. There are transitional modes, too.
I’d rather there be less divergence between Hack and PHP, to limit
the damage that it causes to the community.I don't see any damage to the community. How PHP not matching other
language's syntax does any damage to the community? What kind of damage
and where this damage comes from? Are we damaged because PHP arrays and
Perl arrays have different syntax, despite obvious Perl roots in PHP?
The damage is in fragmentation. Hack threatens to fragment the PHP community by making people jump ship to use its added features. While the whole Hack community can use PHP libraries, only some of the PHP community (HHVM users) can use Hack code. The consequences of this could be severe.
I’d rather there are less differences between PHP and Hack so there are less reasons to switch. Though I suppose the specific syntax of types is probably not a major issue.
--
Andrea Faulds
http://ajf.me/
Hi!
Again, an unfair comparison. Hack isn’t intended to be a completely
I'm not sure what you refer to by "fair". Hack is not "intended", but IS
a separate language - just read the manual and you will see, it is a new
language which borrows some syntax from PHP. Just read their own site:
Hack is a programming language for HHVM that interoperates seamlessly
with PHP.
I completely agree with this statement - Hack is a programming language
that is different from PHP but built in a way to interoperate with it.
separate language. It’s supposed to be an augmented PHP, which is
The fact that you can run (some) PHP code in Hack is a feature of Hack,
the same way as if you craft Perl code I'm sure there is some code that
you can run with minimal modification in PHP. So what?
I'm not sure what you mean by "augmented" - you can claim C++ is an
"augmented assembly language" since you can insert assembly pieces into
C++ code and it would work. But that would make little sense, since C++
goes way beyond and is a separate language. That yes, with some
iterations, borrowed some things (one may say too many if so inclined)
from lower-level languages, but it does not mean it is any of those.
compatible with PHP. PHP code can use Hack code (in HHVM, anyway) and
PHP code can use C, C++, Java or Lua code with suitable extensions. So
what?
Hack code can use PHP code. Hack is a superset of PHP. There are
transitional modes, too.
I'm not sure how this is relevant. Hack is a new language and a new
project, with its own design, its own rules, its own governorship, its
own community, its own everything. It's not something that is an
opinion, it's an obvious fact. Trying to present it as if it is some
part of PHP project just makes no sense to me.
Yes, it build on PHP and it is great for many practical and theoretical
reasons. But it does not change the plain fact of Hack being its own
project and its own language. I honestly do not understand why
recognition of this simple fact is such an issue.
The damage is in fragmentation. Hack threatens to fragment the PHP
community by making people jump ship to use its added features. While
I don't understand that "jump ship" mentality. In last couple of months,
I have used at least 6 different programming languages (not counting
stuff like config languages, shell scripts, etc.) Did I "jump ship"
every time? If I use PHP, am I somehow married to it and using another
language is somehow becomes "cheating"? Is it the case that once I use
Hack I somehow not allowed to use PHP again because I "jumped ship"?
What is that "jumping" thing?
I say - let people use Hack as much as they want. Let them use PHP as
much as they want. Let them use anything their heart likes as much as
they want. There's absolutely no "damage" or "threat" in that. PHP is
not diminished because somebody is using another language, even if that
language uses dollars before variable names. If PHP is ever diminished,
the only reason would be because PHP is not serving its community needs
well enough anymore. That what we should be thinking about - how to make
PHP better suited for its users, not how to prevent people from using
other languages.
the whole Hack community can use PHP libraries, only some of the PHP
community (HHVM users) can use Hack code. The consequences of this
could be severe.
I do not see any "severe" consequences on that at all. If there are Hack
libraries that are so awesome PHP community wants them, they'll be
ported or interfaced - as happened to number of other libraries.
I’d rather there are less differences between PHP and Hack so there
are less reasons to switch. Though I suppose the specific syntax of
types is probably not a major issue.
If you need Hack, by all means use Hack. There's absolutely no problem
and no threat in this. If you need PHP, use PHP. I think our work here
is to make PHP better, not somehow prevent people from using Hack or
change PHP in a way that would make people less inclined to use Hack.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi all,
On Tue, Nov 4, 2014 at 5:50 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Again, an unfair comparison. Hack isn’t intended to be a completely
I'm not sure what you refer to by "fair". Hack is not "intended", but IS
a separate language - just read the manual and you will see, it is a new
language which borrows some syntax from PHP. Just read their own site:Hack is a programming language for HHVM that interoperates seamlessly
with PHP.I completely agree with this statement - Hack is a programming language
that is different from PHP but built in a way to interoperate with it.
I agree with Stas also.
We may have both for compatibility and consistency. Hack may adopt later if
they want.
e.g.
Both
class Bar { public Foo $var; function( Foo $var); }
and
class Bar { public $var : Foo; function($var : Foo); }
may be accepted under PHP. Not many people care about a little compile time
overhead today.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
PHP doesn’t need more inconsistency, sure, but we must be practical
here. It is bad if PHP and Hack have the same feature with different
syntax, it will cause developer confusion and further segment the
communities.Given that Hack is a different language, which was designed AFAIK with
little input from PHP community, I don't see how there would be any
confusion - it's like saying PHP and Perl or PHP and Java having
different syntaxes leads to segmenting the communities. In fact, there
are two different communities - though, of course, people can belong to
both - and two different languages. I do not think Hack syntax should
have much weight in decisions about what syntax to choose in PHP - it's
a different language, even though it has many similarities.
I have to agree with you here.
Hack did not ask us for any of the specific things they did, whether we
plan to do it, propose RFCs to get consistent syntax and behaviors for both
projects.
I tend to think it was on purpose and we should not base our decisions on
hack. That does not mean we cannot map one feature or another but let stay
independent, they can change that for any future changes if they wish
consistencies between the two projects.
-----Ursprüngliche Nachricht-----
Von: Andrea Faulds [mailto:ajf@ajf.me]
Gesendet: Montag, 3. November 2014 16:40
An: Robert Stoll
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Types on the right or on the leftIt adds the type hint on the right hand side of the function (of the
identifier). In contrast to parameters where the type hint is placed on the left hand side of the identifier.
Mixing both, having some types on the left and others on the right,
seems like another inconsistency in the language design to me.These inconsistencies exist for two reasons:
- Opposition to doing it the other way
- Hack already doing it this way
I don’t think
function void foo();will happen, since that’s been previously rejected as it breaks gripping for “function foo”.
Similarly, I don’t thinkpublic $foo: Foo;will happen, given Hack does it aspublic Foo $foo;.PHP doesn’t need more inconsistency, sure, but we must be practical here. It is bad if PHP and Hack have the same feature
with different syntax, it will cause developer confusion and further segment the communities. It is bad if we don’t get
return type hinting because the “consistent” syntax would upset some people.--
Andrea Faulds
http://ajf.me/
I agree with you to a certain degree, PHP and Hack should not diverge but (kind of <b>but</b>)...
IMO Hack made a wrong language design decision and I do not see why PHP should make the same mistake. And I am sure, Hack would catch up quickly if PHP would decide to put all types on the right (as in the return type hint RFC - just as an example).
Hi all,
It adds the type hint on the right hand side of the function (of the
identifier). In contrast to parameters where the
type hint is placed on the left hand side of the identifier.
Mixing both, having some types on the left and others on the right,
seems like another inconsistency in the language
design to me.These inconsistencies exist for two reasons:
- Opposition to doing it the other way
- Hack already doing it this way
I don’t think
function void foo();will happen, since that’s been
previously rejected as it breaks gripping for “function foo”. Similarly, I
don’t thinkpublic $foo: Foo;will happen, given Hack does it aspublic Foo $foo;.
I agree with Andrea.
There are people who dislike syntax, and/or thinks PHP missing check(i.e.
array format, etc). These people should request DbC.
DbC is more powerful than simple type checks and have no performance
penalty in production. (I'm not saying type hinting is
useless. I'll use it where it is appropriate, too.)
I wish I have time for diving into Zend code, but it would not happen in
short term. Therefore, I'm hoping someone to implement DbC :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
Mixing both, having some types on the left and others on the right,
seems like another inconsistency in the language
design to me.These inconsistencies exist for two reasons:
- Opposition to doing it the other way
- Hack already doing it this way
I don’t think
function void foo();will happen, since that’s been
previously rejected as it breaks gripping for “function foo”. Similarly, I
don’t thinkpublic $foo: Foo;will happen, given Hack does it aspublic Foo $foo;.I agree with Andrea.
There are people who dislike syntax, and/or thinks PHP missing check(i.e.
array format, etc). These people should request DbC.
DbC is more powerful than simple type checks and have no performance
penalty in production. (I'm not saying type hinting is
useless. I'll use it where it is appropriate, too.)
+1. I have been reading these discussions about type hinting for years. Every time, people try to bring strong typing through various artefacts, because they don't understand the benefits of loose typing. Some years ago, their model was java, today, it is a combination of java and Hack.
Unfortunately, the RFC on return types was approved. It was just a question of time, with all these people pushing during years. Half-backed, short-term solution, attractive at first sight but bringing more problems than it solves... It will probably have catastrophic implications on the 'REAL' solutions someone may propose in the future.
From the beginning, I think that DbC based on phpdoc annotations, with controlled type conversion (which ones are valid, which ones are not) and switched on/off by an INI parameter would be the best solution to provide the restrictions and checks developers are asking for. Unfortunately, half-backed, short-term solutions, like return types and type hinting, will make proposing such a solution harder, as we will need to keep BC. It will even be an argument to fight against a better solution.
Cheers
François
Thoughts?
I think you didn't follow the mailing list or read the return types
RFC carefully if you think putting the return type before the function
name is good at all. Also, why are you starting this conversation now
instead of months ago or even a couple weeks ago when I asked for
feedback on the latest return types RFC?
Lastly, I want to say that compatibility with Hack is only one
consideration of all things considered. Please don't let that guide
your thoughts too far one way or the other.
-----Ursprüngliche Nachricht-----
Von: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] Im Auftrag von Levi Morrison
Gesendet: Montag, 3. November 2014 19:54
An: Robert Stoll
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Types on the right or on the leftThoughts?
I think you didn't follow the mailing list or read the return types RFC carefully if you think putting the return type before the
function name is good at all. Also, why are you starting this conversation now instead of months ago or even a couple
weeks ago when I asked for feedback on the latest return types RFC?Lastly, I want to say that compatibility with Hack is only one consideration of all things considered. Please don't let that
guide your thoughts too far one way or the other.
You obviously took it the wrong way, I did not intend to attack your RFC. Besides, I wrote an email to you in private mentioning that it is an inconsistency, but that this should not stop your RFC (and thus I have written it in private and did not mention it on the list).
The discussion I wanted to start is not about your RFC, it is about what direction PHP wants to go when it comes down to further type hints, put types only on the right, or only on the left or mix it.
I followed the return type RFC and thus know that many people think it has to be on the left hand side. Fair enough, I do not have anything against such a decision. I also have nothing against putting the type on the right hand side. What merely bothers me is that it would be another inconsistency in the language design. It's not very intuitive for a user if a type hint is once on the right hand side and once on the left hand side.
Hi!
put types only on the right, or only on the left or mix it. I
followed the return type RFC and thus know that many people think it
has to be on the left hand side. Fair enough, I do not have anything
against such a decision. I also have nothing against putting the type
on the right hand side. What merely bothers me is that it would be
another inconsistency in the language design. It's not very intuitive
for a user if a type hint is once on the right hand side and once on
the left hand side.
I agree, this is not a very good situation. It would be much better to
take a systematic approach to this, but this is impossible since there
is no systematic approach to strict typing in PHP, just some pieces here
and there. I think this is not right, but obviously many people here
disagree and are happy to have the inconsistent syntax. I don't see why
"public Foo function bar()" would be so much worse than "public function
bar() : Foo" but for some reason this possibility wasn't even
considered as far as I can see.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
I don't see why
"public Foo function bar()" would be so much worse than "public function
bar() : Foo"
Because when you grep for "function bar", in future you'd have to know
the return type too.
I like to think of it as:
function bar(): Type $hiddenTmpVar
Hi!
"public Foo function bar()" would be so much worse than "public function
bar() : Foo"Because when you grep for "function bar", in future you'd have to know
the return type too.
Sorry, I do not understand - why to grep for "function bar" you'd have
to know the type? Just grep for "function bar" as you did before.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
"public Foo function bar()" would be so much worse than "public function
bar() : Foo"Because when you grep for "function bar", in future you'd have to know
the return type too.Sorry, I do not understand - why to grep for "function bar" you'd have
to know the type? Just grep for "function bar" as you did before.
Because if that function has a return type, e.g.:
public function Foo bar()
Then you couldn’t grep for “function bar” because of the Foo.
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to have Foo after function.
--
Andrea Faulds
http://ajf.me/
Hi!
"public Foo function bar()" would be so much worse than "public function
bar() : Foo"Because when you grep for "function bar", in future you'd have to know
the return type too.Sorry, I do not understand - why to grep for "function bar" you'd have
to know the type? Just grep for "function bar" as you did before.Because if that function has a return type, e.g.:
public function Foo bar()Then you couldn’t grep for “function bar” because of the Foo.
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();It’d be inconsistent with normal function declarations which would have to have Foo after function.
I don't understand that inconsistency.
public Foo function bar() { }
looks perfectly sane to me. PHP's syntax was very heavily influenced by
C from day 1. In C you have:
static int bar() { }
In PHP the 'function' keyword indicates what follows is a function.
Putting something in between the function keyword and the name of the
function would confuse me. To me "function bar()" is inseparable and is
equivalent to "bar()" in C which makes the above examples consistent
with each other.
-Rasmus
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();It’d be inconsistent with normal function declarations which would have to have Foo after function.
I don't understand that inconsistency.
public Foo function bar() { }
looks perfectly sane to me. PHP's syntax was very heavily influenced by
C from day 1. In C you have:static int bar() { }
In PHP the 'function' keyword indicates what follows is a function.
Putting something in between the function keyword and the name of the
function would confuse me. To me "function bar()" is inseparable and is
equivalent to "bar()" in C which makes the above examples consistent
with each other.
Except static function() and static function foo() already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();It’d be inconsistent with normal function declarations which would have to have Foo after function.
I don't understand that inconsistency.
public Foo function bar() { }
looks perfectly sane to me. PHP's syntax was very heavily influenced by
C from day 1. In C you have:static int bar() { }
In PHP the 'function' keyword indicates what follows is a function.
Putting something in between the function keyword and the name of the
function would confuse me. To me "function bar()" is inseparable and is
equivalent to "bar()" in C which makes the above examples consistent
with each other.Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
static isn't a type it is a scope. You want to expand return types to
also cover scopes? How is that in any way useful?
-Rasmus
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();It’d be inconsistent with normal function declarations which would have to have Foo after function.
I don't understand that inconsistency.
public Foo function bar() { }
looks perfectly sane to me. PHP's syntax was very heavily influenced by
C from day 1. In C you have:static int bar() { }
In PHP the 'function' keyword indicates what follows is a function.
Putting something in between the function keyword and the name of the
function would confuse me. To me "function bar()" is inseparable and is
equivalent to "bar()" in C which makes the above examples consistent
with each other.Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.static isn't a type it is a scope. You want to expand return types to
also cover scopes? How is that in any way useful?
Basically because the return type would depend on the scope that
called it. This is done in production, for better or worse, already:
class A {
public static function make() {
return new static();
}
}
class B extends A {}
var_dump(B::make());
//object(B)#1 (0) {
//}
People have been asking for support; it's just out of the scope of this RFC.
Hi!
Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.
If it is possible, why it's not the part of the RFC? Probably because
there's not much place where it would make sense. So, the only
objections so far have been:
- Foo function bar() somehow is not greppable
- It is not clear that Foo function bar() means function
- We could somehow in some undefined time in the future allow static
there, even though we're designing it right now and we actually do not
allow it and see no reason to allow it. - People would think in "Foo function bar()" "Foo" is somehow type of
the whole function, not its return value, despite PHP having no concept
of function type at all and no means to express such type and no need to
do so. - Using ":" is more consistent, because it's "output type", so it is
not the same as type on parameters. - It's inconsistent with "normal function declarations".
- We discussed it on Stack Overflow, and decided it's not inconsistent.
- "It is weird".
- "It is a no go".
Does this really sound convincing argument to anybody? Because it
definitely doesn't to me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.If it is possible, why it's not the part of the RFC? Probably because
there's not much place where it would make sense.
Actually it's because I don't have the time to verify that it wouldn't
violate type rules and implement it. There is no other reason.
<snip> > 3. We could somehow in some undefined time in the future allow static > there, even though we're designing it right now and we actually *do not* > allow it and see no reason to allow it. <snip>Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.If it is possible, why it's not the part of the RFC? Probably because
there's not much place where it would make sense. So, the only
objections so far have been:
You seem to be under the assumption that I have designed this as THE
RFC for return types, and there will be no others. Quite the contrary:
it has been designed to be incredibly minimal, and has taken into
consideration possible expansions and allowed for them to work. Other
examples not already included are generics and function`
I apologize: my baby managed to send my email premature. I'm not even
sure what hotkey he hit ^^
<snip> > 3. We could somehow in some undefined time in the future allow static > there, even though we're designing it right now and we actually *do not* > allow it and see no reason to allow it.Except
static function()andstatic function foo()already have
meaning, and if we allowed static return types (very possible) that
would be ambiguous. This syntax is a no-go.If it is possible, why it's not the part of the RFC? Probably because
there's not much place where it would make sense. So, the only
objections so far have been:
You seem to be under the assumption that I have designed this as THE
RFC for return types, and there will be no others. Quite the contrary:
it has been designed to be incredibly minimal, and has taken into
consideration possible expansions and allowed for them to work. Other
examples not already included are generics and function signatures as types.
What arguments do you have in favor of doing <return_type> "function" <identifier> "( <parameter_list> ")? So far I haven't heard any
argument for them that is different than the ones against them,
but on top of that I have a real, possible technical reason against
that way.
Hi!
What arguments do you have in favor of doing
<return_type> "function" <identifier> "( <parameter_list> ")? So far I haven't heard any
We already using "type before entity" for parameter typing, and it is a
natural way to do it, both from linguistic perspective (in English, we
say "green house", not "house: green") and it is the way used in all
languages that PHP borrowed the concepts from, such as C, C++, Java,
etc. No language I can think of (excepting Hack) does parameters as
<type> <parameter> but functions as <function> : <type> - they use or
always the former, or always the latter. Making PHP the only language
that uses half that and half this would further add to the reputation of
PHP being inconsistent and haphazard language. If we consistently used
"entity : type", it would be acceptable, though detaching somewhat from
PHP roots. But what is being proposed is to use half this and half that.
And this is not a very good idea, IMHO.
I already wrote all this in previous emails, but for those who
accidentally missed them I don't mind repeating.
Other examples not already included are generics and function
signatures as types.
We did not see any proposal for generics or anything else, but as
examples of C++ and Java amply prove, there's no problems working with
generics and having this syntax. In any case, we do not have any
proposals right now and any argument relating to generics whatsoever, so
telling "oh, my proposal is better because generics and other awesome
stuff that maybe will happen but I'm not telling now" is a meaningless
argument, since it does not specify any connection between your proposal
and generics - it only uses a vague dream of having generics in the
future to hint at nonexistent advantage your proposal would provide in
the present.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
I reformatted Stas' arguments to a form better for point-by-point
discussion; I'm sorry if I lost too much information when doing so.
- It's more "natural" to do a prefixed type.
This is the same thing that I am claiming, just from the opposite viewpoint.
- Type prefixed parameters and type suffixed returns is
unprecedented, outside of Hack.
C++11 adds suffixed types for returns despite having prefixed types
for everything else, including previous return types.
- Claiming compatibility for things which aren't proposed is meaningless.
People have already asked for support for static return types; doing
<return_type> "function" <identifier> "( <parameter_list> ") would
then be ambiguous. This is not some pie-in-the sky issue.
I understand why people might think that compatibility for generics is
meaningless, and can respect that (however, C++ templates and Java
generics are not good examples of how things work, but I see no point
in discussing it in this context; message me off-list if anyone is
interested in talking about it).
Once again I apologize if I haven distilled Stas' arguments incorrectly.
In summary, and relevant to the point of the original discussion:
prefixed return types are just not possible if we want to support
'static' return types and keep the ability the current search
semantics for function declarations. Or rather, nobody has proposed
something that would work for both outside of what I am suggesting in
the return type RFC.
Hi!
C++11 adds suffixed types for returns despite having prefixed types
for everything else, including previous return types.
C++ does it for entirely different reasons, related to scoping, and it
still has "auto" type at the beginning. In any case, I'd be very vary
taking late C++ hacks as a guide for syntax, as advanced C++ syntax is
not something I would recommend as an example of clarity.
- Claiming compatibility for things which aren't proposed is meaningless.
People have already asked for support for static return types; doing
People asked for a lot of things, it doesn't mean it makes sense.
"static" as return type doesn't, since it does not specify any type at
all - it just says "I will return a type that is this class or derived
from this class" - which is the same as saying 'self'. There's no
additional information one can gather from 'static' declaration which is
not in 'self' declaration, and I see no use case to ever use it.
<return_type> "function" <identifier> "( <parameter_list> ")would
then be ambiguous. This is not some pie-in-the sky issue.
It's not, it's a non-issue at all, since "static" does not make sense in
that context.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
I would like to pick up this discussion again - now that the return type hint RFC has passed, congratulations :)
As a quick reminder, this discussion should not be whether we want to put the return types on the left or on the right but mainly if we want to have consistency (I do not want to downgrade the return type hint RFC either, that is the reason why I have waited till the vote was closed). Once agreed upon that consistency should be key when it comes down to the place of type hints, we can then discuss what approach PHP shall take in the future (all left or all right).
The more I think about it the more I am in favour of putting types on the right hand side. I think it is more readable and less ambiguous. Consider the following:
class A{
private Foo $a; //is "Foo" a modifier as well?
private static $b; //or is "static" a type?
}
vs.
class A{
private $a : Foo;
private static $b;
}
Assuming we will introduce parameter modifiers such as final or similar in the future, then it is also less ambiguous for parameter type hints:
function foo(final A $a, final $b){}
vs
function foo(final $a : A, final $b){}
I am sure people will tell me that such a change (all types on the right, parameter type hints as well) is huge BC and unfeasible. I would agree that it is a huge BC but I would claim it is necessary and manageable. Code could be migrated automatically with an appropriate tool and it does not need to happen for PHP 7 but maybe for PHP 8. Besides, pretty much the same impact has the return type RFC now, because the manual should be updated accordingly to reflect the new syntax IMO. Sounds like lot of work but it should be possible to migrate the docs with a tool. And it needs to be done IMO otherwise the WTF/minute measurement will increase when using PHP (due to lot of "WTF! In the docs the return types are on the left and in code they are on the right hand side") - but maybe I am wrong.
Anyway, I am primarily in favour of consistency - regardless if all left or all right - and mixing both styles is a very bad idea IMO - do you know any language which has taken a mixed approach (besides Hack)?
Cheers,
Robert
Besides, pretty much the same impact has the return type RFC now,
because the manual should be updated accordingly to reflect the new
syntax IMO. Sounds like lot of work but it should be possible to
migrate the docs with a tool.
As I said in another thread, updating the manual is nothing at all like changing the language. It is a single, centrally-controlled set of content, which doesn't have to be compatible with multiple environments, and has a minimum requirement of internal consistency which has been met in some cases with arbitrary conventions unrelated to the language. It may even be possible to change the notation without changing the source, by altering the output templates, but if not, an automated change to use a new convention more similar to new language syntax is a no-brainer.
As for the rest, I don't see the pressing need to break a whole bunch of established syntax here. It will just make it impossible to run code under multiple versions, and brings a very minor benefit.
I'm not even convinced that return types and parameter types are related enough to require consistency in an ideal world. The type hint to the left of a parameter is the type of that parameter, but a return type hint is not the type of the function - if the function were a first-class object, it's type would be "function", or a specific type such as "function(int, string): string". The function annotation means "produces a", not "is a". This isn't a theoretically rigorous argument, but to my mind it gives a sufficient reason for the syntaxes to be chosen independently.
Regards,
Rowan Collins
[IMSoP]
Besides, pretty much the same impact has the return type RFC now,
because the manual should be updated accordingly to reflect the new
syntax IMO. Sounds like lot of work but it should be possible to
migrate the docs with a tool.As I said in another thread, updating the manual is nothing at all like changing the language. It is a single, centrally-controlled set of content, which doesn't have to be compatible with multiple environments, and has a minimum requirement of internal consistency which has been met in some cases with arbitrary conventions unrelated to the language. It may even be possible to change the notation without changing the source, by altering the output templates, but if not, an automated change to use a new convention more similar to new language syntax is a no-brainer.
Assuming that we are using well-formed DocBook for the methodsynopsis
(which at a glance we seem to do) then hopefully the doc renderer can
take care of the change. It will need to change to use a chunking
function, which I'm not familiar with yet. I'm certainly willing to
look into this.
Hi!
Because if that function has a return type, e.g.:
public function Foo bar()Then you couldn’t grep for “function bar” because of the Foo.
And that's not what I have proposed. Would anybody actually read what
I am proposing? Or reading is optional for discussion now?
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();It’d be inconsistent with normal function declarations which would have to have Foo after function.
What's "normal function" and why it would have to have "Foo" after
function? What's wrong with "Foo function bar()"? It reads nicely (at
least in English, where the natural word order is adjective-noun, not
noun-adjective), it does not disrupt any searches, what exactly is wrong
with it?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
If we used this syntax instead, which wouldn’t disrupt grep:
public Foo function bar();
It’d be inconsistent with normal function declarations which would have to have Foo after function.
What's "normal function" and why it would have to have "Foo" after
function? What's wrong with "Foo function bar()"? It reads nicely (at
least in English, where the natural word order is adjective-noun, not
noun-adjective), it does not disrupt any searches, what exactly is wrong
with it?
I suppose it’s alright for normal functions:
Foo function foo() {
}
But it’s rather weird for closures:
$foo = Foo function () {
};
It’s probably doable from a parsing perspective, but it seems really off to me. Having this return type at the start of the expression doesn’t make sense to me.
But this whole discussion is a little pointless given it’s not what will actually be in PHP.
--
Andrea Faulds
http://ajf.me/
Hi!
But it’s rather weird for closures:
$foo = Foo function () { };
Not much weirder than:
$foo = static function () { ... }
which we already have. Putting modifiers in front of the function is
nothing foreign to PHP.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
But it’s rather weird for closures:
$foo = Foo function () { };Not much weirder than:
$foo = static function () { ... }
which we already have. Putting modifiers in front of the function is
nothing foreign to PHP.
This syntax is one reason that this approach is not taken. While
this RFC does not propose or implement a return type of static, it
could be done in the foreseeable future. Your proposed syntax would
then be ambiguous.
I agree, this is not a very good situation. It would be much better to
take a systematic approach to this, but this is impossible since there
is no systematic approach to strict typing in PHP, just some pieces here
and there. I think this is not right, but obviously many people here
disagree and are happy to have the inconsistent syntax. I don't see why
"public Foo function bar()" would be so much worse than "public function
bar() : Foo" but for some reason this possibility wasn't even
considered as far as I can see.
I thought it was inconsistent, but after discussions on StackOverflow, I don't think it actually is. Return types describe the return type of a function, not the type of a function. So there's no reason they have to go before the function name like parameter types do.
Also, it's worth bearing in mind that public Foo function was rejected previously.
--
Andrea Faulds
http://ajf.me/
I agree, this is not a very good situation. It would be much better to
take a systematic approach to this, but this is impossible since there
is no systematic approach to strict typing in PHP, just some pieces here
and there. I think this is not right, but obviously many people here
disagree and are happy to have the inconsistent syntax. I don't see why
"public Foo function bar()" would be so much worse than "public function
bar() : Foo" but for some reason this possibility wasn't even
considered as far as I can see.
I thought it was inconsistent, but after discussions on StackOverflow, I
don't think it actually is. Return types describe the return type of a
function, not the type of a function. So there's no reason they have to go
before the function name like parameter types do.
So, in a sentence:
In PHP, input types go on the left and output types go on the right.
This sounds like a convention that could be established and followed, and
no-one could reasonably call it inconsistent if it was adhered to.
-----Ursprüngliche Nachricht-----
Von: are.you.winning@gmail.com [mailto:are.you.winning@gmail.com] Im Auftrag von Chris Wright
Gesendet: Dienstag, 4. November 2014 12:51
An: Andrea Faulds
Cc: Stas Malyshev; Robert Stoll; PHP Internals
Betreff: Re: AW: [PHP-DEV] Types on the right or on the leftI agree, this is not a very good situation. It would be much better
to take a systematic approach to this, but this is impossible since
there is no systematic approach to strict typing in PHP, just some
pieces here and there. I think this is not right, but obviously many
people here disagree and are happy to have the inconsistent syntax.
I don't see why "public Foo function bar()" would be so much worse
than "public function
bar() : Foo" but for some reason this possibility wasn't even
considered as far as I can see.I thought it was inconsistent, but after discussions on StackOverflow, I
don't think it actually is. Return types describe the return type of a
function, not the type of a function. So there's no reason they have
to go before the function name like parameter types do.So, in a sentence:
In PHP, input types go on the left and output types go on the right.
This sounds like a convention that could be established and followed, and no-one could reasonably call it inconsistent if it
was adhered to.
That is an interesting thought. Yet, where would you put the type of an out parameter then? Nevertheless, you could phrase your convention differently so it makes more sense and well.. in the end we can do whatever we like in PHP and call it xy-convention and the user will have to pick it up and learn it (quite similar to array functions where usually the first argument is array and suddenly it is not the first parameter as with array_key_exists, array_map or array_search). Sure it is no big deal, the user should be able to pick up the convention quickly but we could facilitate it, make it easier for the user, more intuitive, in order that the user has a steeper learning curve. And the time to decide what direction PHP should take is now with PHP 7.
-----Ursprüngliche Nachricht-----
Von: are.you.winning@gmail.com [mailto:are.you.winning@gmail.com] Im
Auftrag von Chris Wright
Gesendet: Dienstag, 4. November 2014 12:51
An: Andrea Faulds
Cc: Stas Malyshev; Robert Stoll; PHP Internals
Betreff: Re: AW: [PHP-DEV] Types on the right or on the leftOn 4 Nov 2014, at 08:51, Stas Malyshev smalyshev@sugarcrm.com
wrote:I agree, this is not a very good situation. It would be much better
to take a systematic approach to this, but this is impossible since
there is no systematic approach to strict typing in PHP, just some
pieces here and there. I think this is not right, but obviously many
people here disagree and are happy to have the inconsistent syntax.
I don't see why "public Foo function bar()" would be so much worse
than "public function
bar() : Foo" but for some reason this possibility wasn't even
considered as far as I can see.I thought it was inconsistent, but after discussions on StackOverflow, I
don't think it actually is. Return types describe the return type of a
function, not the type of a function. So there's no reason they have
to go before the function name like parameter types do.So, in a sentence:
In PHP, input types go on the left and output types go on the right.
This sounds like a convention that could be established and followed,
and no-one could reasonably call it inconsistent if it
was adhered to.That is an interesting thought. Yet, where would you put the type of an
out parameter then?
I wouldn't, because this wouldn't ever make sense in PHP. I'm not a fan of
out parameters in general in PHP, but enforcing the output type of a
variable can't ever make sense in PHP from an implementation perspective
without sacrificing some dynamic features that won't ever disappear - I'm
sure it could be done, but not without a huge and unacceptable performance
penalty.
Nevertheless, you could phrase your convention differently so it makes
more sense and well.. in the end we can do whatever we like in PHP and
call it xy-convention and the user will have to pick it up and learn it
(quite similar to array functions where usually the first argument is array
and suddenly it is not the first parameter as with array_key_exists,
array_map or array_search). Sure it is no big deal, the user should be able
to pick up the convention quickly but we could facilitate it, make it
easier for the user, more intuitive, in order that the user has a steeper
learning curve. And the time to decide what direction PHP should take is
now with PHP 7.
Please remember that PHP 7 is not the last major version of PHP. The things
we do now are set in stone, but they do not mean that something else cannot
be done in the future to build on top of them, as long as they do not
conflict.
I guess it's worth noting that my personal opinion is that I'd also
rather have the function return type declaration on the left (I'd also like
to drop the requirement for the "function" keyword in method declarations),
but since there are a number of reasons why this no longer makes sense, and
will never make sense again, I didn't hesitate to vote in favour of the
current proposal because more than anything else I think the feature is
what is important, and I know how much work has been put in to ensuring
that the proposal satisfies as many concerns as possible. There will never
be a better proposal than this.
I guess it's worth noting that my personal opinion is that I'd also rather have the function return type declaration on the
left (I'd also like to drop the requirement for the "function" keyword in method declarations), but since there are a number
of reasons why this no longer makes sense, and will never make sense again, I didn't hesitate to vote in favour of the
current proposal because more than anything else I think the feature is what is important, and I know how much work has
been put in to ensuring that the proposal satisfies as many concerns as possible. There will never be a better proposal than
this.
To be clear, I would vote yes for the return type RFC if I had voting rights. I'll continue this discussion after the return type RFC's voting phase ended. I do not want to cast a damning light on the RFC.
I thought it was inconsistent, but after discussions on StackOverflow, I don't think it actually is. > Return types describe the return type of a function, not the type of a function. So there's no reason > they have to go before the function name like parameter types do.
So, in a sentence:
In PHP, input types go on the left and output types go on the right.
This sounds like a convention that could be established and followed, and no-one could reasonably call it inconsistent if it was adhered to.
That’s not quite what I meant, but I’d also agree with that convention.
For parameters, the type is of the thing itself:
function foo(Foo $foo, Bar $bar);
Here, $foo is of the type Foo, and $bar is of the type Bar.
But say if we were to add return types like this:
function FooBar qux();
The type of qux isn’t a FooBar, it’s a function (more accurately, an argument-less, return-anything function). FooBar isn’t what qux is, it’s not qux’s type, merely what it returns. In a sense, I’d say there’s already a type here: function.
Compare it to this:
function qux(): FooBar;
FooBar is what qux returns, function is what qux is.
If we were to hypothetically add typed properties with the same syntax Hack has, they’d look like this:
public Foo $foo;
This would be consistent with parameters. And I think it goes along well with return types at the end:
public Foo $foo;
public function foobar(): FooBar;
Here, it’s clear the second item is a function, and the previous item is a property of type Foo.
…but hey, I could be wrong. Does this make sense to anyone?
--
Andrea Faulds
http://ajf.me/
Andrea Faulds wrote:
For parameters, the type is of the thing itself:
function foo(Foo $foo, Bar $bar);Here, $foo is of the type Foo, and $bar is of the type Bar.
But say if we were to add return types like this:
function FooBar qux();The type of qux isn’t a FooBar, it’s a function (more accurately, an argument-less, return-anything function). FooBar isn’t what qux is, it’s not qux’s type, merely what it returns. In a sense, I’d say there’s already a type here:
function.Compare it to this:
function qux(): FooBar;FooBar is what qux returns,
functionis what qux is.If we were to hypothetically add typed properties with the same syntax Hack has, they’d look like this:
public Foo $foo;This would be consistent with parameters. And I think it goes along well with return types at the end:
public Foo $foo; public function foobar(): FooBar;Here, it’s clear the second item is a function, and the previous item is a property of type Foo.
…but hey, I could be wrong. Does this make sense to anyone?
To me it makes sense. However
Foo function foo(Bar bar) {}
also makes sense, as the type of bar would be "Foo function(Bar)".
--
Christoph M. Becker
Hi!
In PHP, input types go on the left and output types go on the right.
What is the "output type"? If I wanted to type a variable - is it input
or output?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
I thought it was inconsistent, but after discussions on
StackOverflow, I don't think it actually is.
If you specify the type once as "Foo something" and once as "something:
Foo" then I don't see how there's even a place for discussions that it's
inconsistent.
Return types describe the return type of a function, not the type of
a function.
Given that in PHP functions do not have types, not being objects of the
language, this seems to be argument invented just to ignore the
inconsistency.
Moreover, in languages where functions do have types - e.g. ML for
example - the return of the function is specified in exactly the same
manner as parameter type, and type of the function itself is never
specified explicitly, but if needed, it is referred to with different
syntax (->). See: https://en.wikipedia.org/wiki/Standard_ML
Same situation with ActionScript: https://en.wikipedia.org/wiki/ActionScript
both parameters and return type use ":" and nobody thinks that specifies
type of the function - as, again, nobody ever specifies type of the
function as such. In fact, I can remember no language that would specify
type of the function (as opposed to parameters + returns) when declaring
a function, even among languages with first class functions.
Also, it's worth bearing in mind that
public Foo functionwas
rejected previously.
Many things were rejected previously, but the RFC does not bring any
argument about it and never even mentions it as far as I can see.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
2014-11-04 9:51 GMT-08:00 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
I thought it was inconsistent, but after discussions on
StackOverflow, I don't think it actually is.If you specify the type once as "Foo something" and once as "something:
Foo" then I don't see how there's even a place for discussions that it's
inconsistent.Return types describe the return type of a function, not the type of
a function.Given that in PHP functions do not have types, not being objects of the
language, this seems to be argument invented just to ignore the
inconsistency.Moreover, in languages where functions do have types - e.g. ML for
example - the return of the function is specified in exactly the same
manner as parameter type, and type of the function itself is never
specified explicitly, but if needed, it is referred to with different
syntax (->). See: https://en.wikipedia.org/wiki/Standard_MLSame situation with ActionScript:
https://en.wikipedia.org/wiki/ActionScript
both parameters and return type use ":" and nobody thinks that specifies
type of the function - as, again, nobody ever specifies type of the
function as such. In fact, I can remember no language that would specify
type of the function (as opposed to parameters + returns) when declaring
a function, even among languages with first class functions.Haskell does:
length :: [a] -> Int
length [] = 0
length (_:xs) = 1 + length xs
Also, it's worth bearing in mind that
public Foo functionwas
rejected previously.Many things were rejected previously, but the RFC does not bring any
argument about it and never even mentions it as far as I can see.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/