Re: [RFC][PRE-VOTE] In Operator

On 3/15/15 11:05 PM, Yasuo Ohgaki wrote: > Hi all, > > On Mon, Mar 16, 2015 at 11:50 AM, Eli <eli@eliw.com> wrote: >> Currently, I can speak for myself, I almost always find myself doing a >> 'backup' step in coding. Because in this situation my process becomes: >> >> if ($zebra ... Oh wait, can't do that, need to use in_array >> >> if (in_array( ... Oh wait, what's the order of parameters again? dang it, >> hit php.net or find a recent use. >> >> if (in_array($zebra,$zoo)) {} ... *shew* >> >> In the end, yes, you can argue that this is a small thing. But I believe >> that the simpler cognitive path that one follows with this new syntax will >> bring some great benefit to coders. > This is one of the issue what I'm trying to fix by this RFC. > https://wiki.php.net/rfc/consistent_function_names > This would be better fix for this issue. > Note: I added parameter issue handling to the RFC. However your proposal here (it's own merits aside), doesn't actually address what I mentioned. Since it still requires the use of a 'function first' phraseology instead of a more natural language one. If anything, it actually might hurt this one specific case. Because at least now, the function has a logical process to it, if you think about it. IE: in_array(what, array). Whereas switched as your proposal allows for: array_in(what, array). Means the function name is kinda backwards comparatively. Also, it reads as if it's something else. I'd expect by natural language, that array_in ... would look for an array in something. Not the other way around. Eli -- | Eli White | http://eliw.com/ | Twitter: EliW |

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc