Re: Re: [RFC] [DISCUSSION] Consistent Function Names
| From: | Yasuo Ohgaki | Date: | Fri, 06 Mar 2015 23:03:26 +0000 |
| Subject: | Re: Re: [RFC] [DISCUSSION] Consistent Function Names | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84389@lists.php.net to get a copy of this message | ||
Hi Jordi,
On Thu, Mar 5, 2015 at 7:30 PM, Jordi Boggiano <j.boggiano@seld.be> wrote:
> On 05/03/2015 08:07, Yasuo Ohgaki wrote:
>
>> So array functions are subject to be changed.
>>
>> bool in_array ( mixed $needle , array $haystack [, bool $strict ] )
>> Renamed to array_in() and fix order.
>>
>> mixed array_search ( mixed $needle , array $haystack [, bool $strict
>> ] )
>> Renamed to array_find() and fix order.
>>
>> bool array_key_exists ( mixed $key , array $array )
>> Renamed to array_key_find() and fix order.
>>
>> array array_keys ( array $array [, mixed $search_value [, bool $strict =
>> false ]] )
>> OK as it is now.
>>
>> implode() may be changed to have
>> string implode ( string $glue , array $pieces )
>> always.
>>
>
> If we do create new array functions I think it should be thought through a
> bit more than just cleaning up the arg order. For example we could support
> Traversable as well. Then at least it'd bring some value beyond consistency
> for the sake of it.
I agree. Do you have more detailed suggestion for this?
http://ruby-doc.org/core-2.2.0/Array.html
https://docs.python.org/3/tutorial/datastructures.html
https://docs.python.org/2/library/array.html
https://scipy-lectures.github.io/intro/numpy/array_object.html
We have a lot of array_u*() functions such as
http://php.net/manual/en/function.array-uintersect-uassoc.php
array array_uintersect_uassoc ( array $array1 , array $array2 [, array $...
], callable $value_compare_func , callable $key_compare_func )
this can be consolidated to
http://php.net/manual/en/function.array-intersect-assoc.php
array array_intersect_assoc ( array $array1 , array $array2 [, array $... ]
)
All of these has callback the end of parameters. These may be consolidated.
I'll add this to the RFC if this is preferred.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net