Re: [PHP-DEV] Types on the right or on the left
> On 3 Nov 2014, at 15:07, Robert Stoll wrote: > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> On 3 Nov 2014, at 19:28, Stas Malyshev wrote: > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> On 3 Nov 2014, at 19:48, Stas Malyshev wrote: > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> On 4 Nov 2014, at 11:50, Chris Wright wrote: > > On 4 November 2014 10:32, Andrea Faulds wrote: > > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> On 4 Nov 2014, at 17:46, Stas Malyshev wrote: > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On 11/04/2014 10:08 AM, Andrea Faulds wrote:
>
>> On 4 Nov 2014, at 17:46, Stas Malyshev wrote:
>>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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, `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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
> On 4 Nov 2014, at 18:33, Stas Malyshev wrote:
>
>> 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On Tue, Nov 4, 2014 at 11:48 AM, Stas Malyshev wrote:
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
>> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On 11/04/2014 04:42 PM, Levi Morrison wrote:
>>> 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > 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 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: 1. Foo function bar() somehow is not greppable 2. It is not clear that Foo function bar() means function 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. 4. 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. 5. Using ":" is more consistent, because it's "output type", so it is not the same as type on parameters. 6. It's inconsistent with "normal function declarations". 7. We discussed it on Stack Overflow, and decided it's not inconsistent. 8. "It is weird". 9. "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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On Tue, Nov 4, 2014 at 5:55 PM, Rasmus Lerdorf wrote:
> On 11/04/2014 04:42 PM, Levi Morrison wrote:
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.
>
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On Tue, Nov 4, 2014 at 6:05 PM, Stas Malyshev wrote: > Hi! > >> 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 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
>> 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 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: > > 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. 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` -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
I apologize: my baby managed to send my email premature. I'm not even sure what hotkey he hit ^^ >> 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 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: > 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. 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 ` "function" "( ")`? 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi! > What arguments do you have in favor of doing ` "function" > "( ")`? 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 but functions as : - 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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. 1) It's more "natural" to do a prefixed type. This is the same thing that I am claiming, just from the opposite viewpoint. 2) 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. 3) Claiming compatibility for things which aren't proposed is meaningless. People have already asked for support for static return types; doing ` "function" "( ")` 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
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. > 3) 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. > ` "function" "( ")` 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On Nov 4, 2014 5:28 AM, "Stas Malyshev" wrote: > > 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.
Re: [PHP-DEV] Types on the right or on the left
On 24 January 2015 11:09:04 GMT, Robert Stoll wrote: >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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
On Sat, Jan 24, 2015 at 7:42 AM, Rowan Collins wrote: > On 24 January 2015 11:09:04 GMT, Robert Stoll wrote: > >>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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Types on the right or on the left
Hi all, On Tue, Nov 4, 2014 at 12:39 AM, Andrea Faulds wrote: > > On 3 Nov 2014, at 15:07, Robert Stoll wrote: > > > > 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;`. > 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 yohg...@ohgaki.net
Re: [PHP-DEV] Types on the right or on the left
Hi all,
On Tue, Nov 4, 2014 at 5:50 AM, Stas Malyshev
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
yohg...@ohgaki.net
RE: [PHP-DEV] Types on the right or on the left
> De : yohg...@gmail.com [mailto:yohg...@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 think `public $foo: Foo;` will happen, given Hack does it as `public > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
