Hi,
On Tue, Mar 18, 2014 at 1:28 PM, Rouven Weßling <[email protected]> wrote:
>
> On 18.03.2014, at 12:17, Leigh <[email protected]> wrote:
>
>> I might be missing something but I have to agree with
>>
>> On 18 March 2014 07:44, Stas Malyshev <[email protected]> wrote:
>>>
>>> Doing to all this length for what? To rename a function? Looks hardly
>>> worth it.
>>
>>
>> The method is named as it is in userland because it maps 1:1 with the
>> underlying interface
>>
>> open -> open
>> destroy -> destroy
>> create_sid -> create_sid
>>
>> Seems like a big waste of time, and hassle for people who use it, when you
>> go around renaming things for the sake of it. Especially when that's all it
>> is, a rename, no extra functionality.
>
> I agree, that's hardly worth it. I guess part of the problem in this case was that it
> never went trough an RFC (At least I didn't know about it, since it was never documented I
> think it's hardly known at all). What would be great if we could get some clear cut naming
> conventions for user land APIs otherwise we will keep making the API more inconsistent. The fact,
> that it is mirroring the internal interface is a really bad argument. PHP is a high level language
> and should abstract these concerns away from users.
Couldn't have said it better.
Most OO APIs use camelCase, so I guess this was why Yasuo assumed it
and proposed this change. I think we should stick to that ... only
mysqli comes to mind that uses snake_names and that's probably because
it tries to mirror procedural functions.
Cheers,
Andrey.