On 3/15/15 11:05 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Mar 16, 2015 at 11:50 AM, Eli <e...@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 |
signature.asc
Description: OpenPGP digital signature
