Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies "consistent with what rules?"
It's possible choice.
I agree that names without "_" looks more consistent.
Personally, I don't care much about having "_" or not for procedural API. My
only concern is naming consistency.
Names without "_" changes basic coding rule.
Problem is how to make a choice and how to define exceptions. e.g.
nl_langinfo()
I wonder how many of us prefer names without "_".
The one thing that your RFC demonstrates perfectly is just how much has
to change to match that rule. Change the rule and the number of names
that need alternatives is considerably less. I know a case was made at
the time for adding underscores to the guidelines but it's quite clear
that this was the mistake?
PHP function names are case insensitive, and conventionally written in
lower-case (a convention that nothing decided on this list will change),
so underscores are important for readability.
To take an example Yasuo has mentioned a couple of times, pg_lo_open()
without any underscores at all would be pgloopen(), which is very hard
to read: it could be pGloopen(), pgLoopEn(), pGlooPen(), pgLoOpen(), etc.
For whatever reason, PHP's users decided to go with camelCase
identifiers for methods, rather than underscores. I don't think that was
a decision that originated in the core distribution (which for a long
time had very few object APIs), and I don't think it's one that can be
changed by the core distribution (or, at this stage, anyone).
If PHP had had namespaces from day 1, and camel-case conventions, it
would have been pg\loOpen(), but we can't change history.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
