Re: [RFC][Discuss] Arrow Functions

Hi Ilija > On 4 Feb 2017, at 17:09, ilija.tovilo@me.com wrote: > > Hi Stephen > >> Using type hints is a part of the language. It even has benefits that I can absolutely see >> being used here: >> >> array_map(function(Foo $x) => $x->bar()); >> >> If Foo is a class/interface with a method of bar, your IDE can know that it's a valid >> method to call. >> >> That of course is in addition to the benefit of getting useful type errors from PHP itself. > > I agree but think that this is the wrong approach. PHP is a weakly typed language. Only if you omit type hints on your methods. > Doesn’t it seem wrong that you have to specify types in more places than in many modern > strongly typed languages? You don't *have to* specify types at all. If you want to use PHP without verifying/requiring types, thats your prerogative, but given the recent improvements to allow scalar type hinting, I think it’s a mistake to say that *any* use of type hints is “not recommended". > Look at Swift for example. IMHO, the right approach would be to implement proper closure type > hints. This has the benefit of letting the callee specify what kind of closure is expected (who > knows that much better than the caller anyway) while allowing for IDE autocompletion. I'm not sure if you've mixed up your terms of if I'm too tired but I don't understand what you mean here. The short arrow function *is* the callee, and that’s where you’re suggesting we shouldn’t use type hints. Are you actually referring to something like https://wiki.php.net/rfc/callable-types <https://wiki.php.net/rfc/callable-types> or https://wiki.php.net/rfc/typesafe-callable <https://wiki.php.net/rfc/typesafe-callable> where a callable type hint can define the signature the callable should match? > Nonetheless, specifying type hints on the closures is what we do right now. The approach Levi > suggested works well with that. The whole issue with that is that using a pipe character could make things much less clear/readable if the already established use of pipe for “type unions” (currently used in multi-catch) were to be implemented for general type hint usage. Note: I’m not saying it’s not possible, but it’s *much* less readable, and any “solution” just adds more characters, which is apparently the only reason to not use function($foo) => $foo in the first place. > >> So we should instead use syntax already used for bit wise OR, and further confuse the >> situation when the function has no parameters and reusing the logical OR operator. Brilliant. >> >> This is still a function, it has slightly different semantics, just like how a regular >> function, a class instance method and a static class method have slightly different semantics: we >> still use the function keyword for all of those. >> >> The static keyword is used for functions, class static properties, static variables and >> even static closures: it's semantics are slightly different for each case but we reuse the same >> keyword. > > As Levi already mentioned, this argument is similar to claiming reusing the > function keyword could be confusing. That was my point. There's no 'confusion' reason to not use function. The *only* reason is to make it less characters, which several people have noted doesn't automatically make it more readable. > Both should be perfectly clear to anyone who is serious about programming. I think we can > expect for programmers to get informed about new features before using them. This seems to work for > any other language. Also, it’s not like the suggested syntax is something we’ve never seen > before. Ruby has it, Rust has it (or something similar at least). The rest personal preference I > suppose. > As has been mentioned, the rust syntax can get very hard to read very quickly. > I can see how people like function more because of consistency. > I like || => expr more because of readability (for me, the less > reading the better :P). For most people readability isn't just about the number of characters. Cheers Stephen