Hi Ilija > On 4 Feb 2017, at 17:09, ilija.tov...@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
