On Thu, Feb 13, 2020, at 2:12 PM, Mike Schinkel wrote:
> > On Feb 13, 2020, at 1:48 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> >> But since I seem to be in the minority of caring about the name, let me
> >> propose the following which was influenced by Larry Garfield's most
> >> recent post. Since it seems that people want the convenience of a
> >> short notation to get a closure, how about this:
> >>
> >> function foo{}
> >>
> >> foo::function — Returns name of function
> >> foo::fn — Returns closure for function
> >>
> >> Since using `fn` creates anonymous function closures it kinda makes
> >> sense that `::fn` would return a closure.
> >>
> >> -Mike
> >
> > thinking-face-emoji.gif. I could be convinced of that. It seems like
> > "both" is a possible solution, but my concern would be someone using one of
> > them in a case where either works, inadvertently, when the callee is
> > expecting just one. Eg, getting into the habit of using foo::fn, and then
> > using it on a builder routine that chokes "later" when it tries to
> > serialize something.
>
> True.
>
> But it would be a really high bar to say we can only add new features
> if we can completely protect the developer from themselves. At some
> point we have to assume programmers are adults, or at least can take
> responsibility for learning how the language works.
Strawman argument. Nothing can "completely" protect developers from
themselves; not even Rust. :-) But features should still be designed in such a
way as to be hard to screw up. Not impossible, hard.
The question I pose is whether "both" would be "hard enough" to get wrong that
it's not going to cause more confusion than it solves. I don't know the answer
to that question.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
