Hi Folks,
I really like the idea from Larry Garfield or Pierre Joye's proposal (3).
We now do have some things cluttered, and it does not matter because
of what this is cluttered or if it's only the C world shining through.
Programmatically spoken, to me and many OO folks, these things are
inconsitently named and the strlen("somesting")... syntax is very
1980s to have.
Anyways, any change should not break existing code, but must strive
for new code being written to be more maintainable, readable and
OOP-like.
Either these functions must live in this space forever (and can get
proper aliases or mappings to OO-compliant syntax), or, if one tends
to disable them, we could have some switch in INI or in a script,
enabling all of them back again, like
init_set('PHP5_FUNC_COMPAT', true);
For old projects that depend on them, the main PHP include would then
include this flag and the functions would be made available.
Cheers,
Nils
2014/1/2 Pierre Joye <[email protected]>:
> On Dec 28, 2013 1:58 PM, "Yasuo Ohgaki" <[email protected]> wrote:
>>
>> Hi all,
>>
>> I know this has been discussed before, but I'll try again.
>> We have following coding standard
>>
>> 1. Function names for user-level functions should be enclosed with in
>> the PHP_FUNCTION() macro. They should be in lowercase, with words
>> underscore delimited, with care taken to minimize the letter count.
>> Abbreviations should not be used when they greatly decrease the
>> readability of the function name itself::
>
> There are a couple of solutions to this problem.
>
> 1. Change all the existing functions signatures. Bad idea per se as we can
> forget any fast adoption, if any at all. Will be very painful to migrate
> existing code
>
> 2. Add aliases all around.
> Not a big fan of that one either. It clutters the php NS a lot without
> factual gains
>
> 3. Try to implement nickic's prototype to add methods to scalar related
> types, should work with complex types as well
>
> I would prefer to give 3. a try, while it could be tricky to implement a
> technically acceptable solution.
>
> Pros:
>
> . It will bring consistent APIs
> . does not add dozen of aliases for little gains
> . fully BC
> . fits more to current development habits
>
> Cons:
> . still have to be careful by designing the new "methods"
>
> Cheers,
> Pierre