Flexible function naming

11 years ago by Robert Cerny — view source — reply

unread

Hello,

I am new to the list. I have been a PHP user for 8 years. I am a
progammer for 30 years. Initially i wanted to post this as an RFC, but
could not figure out how to register. When accessing [1] i get 'Command
disabled: register'. I did some research, but the archives are vast, so
please accept my apologies in advance if this has already been discussed.

When a PHP code base is growing over time it looks more and more
'diverse', because of inconsistent function and method naming in core
PHP and third party libraries. This cannot be changed by any guidelines.
The author of a function has the freedom to assign any name. The user of
a function needs some flexibility in referring to a function. It should
be possible to use 'array_key_exists', 'arrayKeyExists' or
'arraykeyExists'. Because of the performance impact and possible
resolution conflicts this language feature needs to be disabled by default.

This is not difficult to implement. It is only necessary to normalize
function names: remove all but leading underscores and lower case the
result. The likelihood of conflict is very small.

This small change would allow coding teams to create a consistent code
base based on 'their' guidelines. Motto: "Have it your way!".

Best regards,

Robert Cerny

[1] https://wiki.php.net/start?do=register

11 years ago by Michael Wallner — view source — reply

unread

Hello,

I am new to the list. I have been a PHP user for 8 years. I am a
progammer for 30 years. Initially i wanted to post this as an RFC, but
could not figure out how to register. When accessing [1] i get 'Command
disabled: register'. I did some research, but the archives are vast, so
please accept my apologies in advance if this has already been discussed.

Yes one cannot register.

When a PHP code base is growing over time it looks more and more
'diverse', because of inconsistent function and method naming in core PHP
and third party libraries. This cannot be changed by any guidelines. The
author of a function has the freedom to assign any name. The user of a
function needs some flexibility in referring to a function. It should be
possible to use 'array_key_exists', 'arrayKeyExists' or 'arraykeyExists'.
Because of the performance impact and possible resolution conflicts this
language feature needs to be disabled by default.

Oh, I think this is not the best example, but in 5.6 you can achieve that
with the new 'use function' feature.

This is not difficult to implement. It is only necessary to normalize
function names: remove all but leading underscores and lower case the
result. The likelihood of conflict is very small.

This small change would allow coding teams to create a consistent code
base based on 'their' guidelines. Motto: "Have it your way!".

No.

Best regards,

Robert Cerny

[1] https://wiki.php.net/start?do=register

11 years ago by Robert Cerny — view source — reply

unread

Michael Wallner wrote:

[...]

When a PHP code base is growing over time it looks more and more
'diverse', because of inconsistent function and method naming in core
PHP and third party libraries. This cannot be changed by any
guidelines. The author of a function has the freedom to assign any
name. The user of a function needs some flexibility in referring to a
function. It should be possible to use 'array_key_exists',
'arrayKeyExists' or 'arraykeyExists'. Because of the performance
impact and possible resolution conflicts this language feature needs
to be disabled by default.

Oh, I think this is not the best example, but in 5.6 you can achieve
that with the new 'use function' feature.

That is not what i mean. My proposal reaches much further. In the
meantime, i realized how to do it with minimal performance impact. Upon
parsing, PHP would need to add synonyms for function and method names to
the namespace depending on the configured referral styles. By
'namespace' i do not mean a declared PHP namespace in the formal sense.
By default no referral styles are configured. Users can choose between
'camel case' and 'underscore'. In this case there would be no need to
normalize function names when looking up a symbol. It would be built-in
glasses feature, for those who know the emacs mode.

This is not difficult to implement. It is only necessary to
normalize function names: remove all but leading underscores and lower
case the result. The likelihood of conflict is very small.

This small change would allow coding teams to create a consistent
code base based on 'their' guidelines. Motto: "Have it your way!".

No.

What is wrong with having a consistent code base all the way, also
covering legacy code? I consider this a pretty neat language feature.

Robert

11 years ago by Tjerk Meesters — view source — reply

unread

On Mon, Dec 16, 2013 at 1:47 PM, Robert Cerny robert@cerny-online.comwrote:

Michael Wallner wrote:

[...]

When a PHP code base is growing over time it looks more and more
'diverse', because of inconsistent function and method naming in core PHP
and third party libraries. This cannot be changed by any guidelines. The
author of a function has the freedom to assign any name. The user of a
function needs some flexibility in referring to a function. It should be
possible to use 'array_key_exists', 'arrayKeyExists' or 'arraykeyExists'.
Because of the performance impact and possible resolution conflicts this
language feature needs to be disabled by default.

Oh, I think this is not the best example, but in 5.6 you can achieve that
with the new 'use function' feature.

That is not what i mean. My proposal reaches much further. In the
meantime, i realized how to do it with minimal performance impact. Upon
parsing, PHP would need to add synonyms for function and method names to
the namespace depending on the configured referral styles. By 'namespace' i
do not mean a declared PHP namespace in the formal sense. By default no
referral styles are configured. Users can choose between 'camel case' and
'underscore'. In this case there would be no need to normalize function
names when looking up a symbol. It would be built-in glasses feature, for
those who know the emacs mode.

This is not difficult to implement. It is only necessary to normalize
function names: remove all but leading underscores and lower case the
result. The likelihood of conflict is very small.

This small change would allow coding teams to create a consistent code
base based on 'their' guidelines. Motto: "Have it your way!".

No.

What is wrong with having a consistent code base all the way, also
covering legacy code? I consider this a pretty neat language feature.

Consistency doesn't stop at how functions are named; there are enough
functions that have an unintuitive order of function parameters, this isn't
addressed in your proposal.

If it were just the naming you wish to address, I would suggest writing an
extension first and see how that catches on.

Robert

--

--

Tjerk

11 years ago by Robert Cerny — view source — reply

unread

Tjerk Meesters wrote:

This small change would allow coding teams to create a consistent code
base based on 'their' guidelines. Motto: "Have it your way!".

No.

What is wrong with having a consistent code base all the way, also
covering legacy code? I consider this a pretty neat language feature.
Consistency doesn't stop at how functions are named; there are enough
functions that have an unintuitive order of function parameters, this isn't
addressed in your proposal.
You are right. There is more reasons for the inconsistent appearance of
a large PHP code base. The one that you mentioned is IMHO a major
annoyance while authoring code, it is only minor when reading code, in
particular if you keep the numbers of function arguments small.
If it were just the naming you wish to address, I would suggest writing an
extension first and see how that catches on.
Thanks, that is helpful. I look into that!

Robert

11 years ago by Rowan Collins — view source — reply

unread

Robert Cerny wrote (on 14/12/2013):

When a PHP code base is growing over time it looks more and more
'diverse', because of inconsistent function and method naming in core
PHP and third party libraries

This comes rather close to ignoring one of the pieces of advice on "The
Mysterious PHP RFC Process and How You Can Change the Web" 1 which is
linked to from the RFC HowTo on the PHP wiki 2:

Don't start an RFC (or mail list discussion) about standardizing PHP
function names and function argument orders

We all know that PHP's core functions are drastically inconsistent, but
you need to be very sure you have a new and simple approach to solving
that problem before expecting much enthusiasm for it.

It should be possible to use 'array_key_exists', 'arrayKeyExists' or
'arraykeyExists'.

This looks to me like making the language more inconsistent, not less.
Why should different projects be able to call the same built-in function
by different names?

If you're thinking more of third-party code not having matching coding
conventions, then you might be interested in the work of the Framework
Interoperability Group 3 who are aiming to agree a set of voluntary
standards for just this kind of thing. That doesn't need any changes to
the core language, just for framework and library authors to use an
agreed set of conventions.

Regards,

Rowan Collins
[IMSoP]

11 years ago by Robert Cerny — view source — reply

unread

Rowan wrote:

[...]

We all know that PHP's core functions are drastically inconsistent,
but you need to be very sure you have a new and simple approach to
solving that problem before expecting much enthusiasm for it.
I cannot judge whether my solution is new, but it is for sure simple.
Somebody with knowledge of the PHP source code can probably solve it
within a day: when hooking a function into a namespace, calculate the
synonyms and hook those in as well.

It should be possible to use 'array_key_exists', 'arrayKeyExists' or
'arraykeyExists'.

This looks to me like making the language more inconsistent, not
less. Why should different projects be able to call the same built-in
function by different names?
My emphasis is on consistency within a project, not between. I am
thinking of applications mainly, not libraries.

If you're thinking more of third-party code not having matching coding
conventions, then you might be interested in the work of the Framework
Interoperability Group [3] who are aiming to agree a set of voluntary
standards for just this kind of thing. That doesn't need any changes
to the core language, just for framework and library authors to use an
agreed set of conventions.
Thanks for pointing that out! Yet, i am interested in a solution that
also covers legacy code and the core.

Robert

11 years ago by Alexander Deruwe — view source — reply

unread

My emphasis is on consistency within a project, not between. I am thinking
of applications mainly, not libraries.

I don't normally post here ... but in this instance I felt compelled.
Given enough developers, this RFC will not help you attain consistency
without your project, quite the contrary, as each developer will
finally reach for "her preferred way".

Wrap it if you don't like it is about the best we can do here, and
really, it's not a huge problem in any case.

Alexander

11 years ago by Robert Cerny — view source — reply

unread

Alexander wrote:

My emphasis is on consistency within a project, not between. I am thinking
of applications mainly, not libraries.
I don't normally post here ... but in this instance I felt compelled.
Given enough developers, this RFC will not help you attain consistency
without your project, quite the contrary, as each developer will
finally reach for "her preferred way".
It is possible to control the coding style of a team, e.g. by
preventing commits that violate the style. I made the experience that
there is no single right way of naming, but consistency within a project
is very helpful. A new senior developer will adjust to the coding style
of the team. Plus if consistency can be recognized by developers, then
deviations are also easier to recognize for junior developers.

Robert

11 years ago by Rowan Collins — view source — reply

unread

If you look at the core PHP functions (e.g. array) and some important
new additions like DateTime, you will see that there is mainly two
styles competing: Underscore and Camelcase, so in most cases it will
be one synonym, sometimes two, but never what you were enumerating.

That's not inconsistency, that's a convention in its own right: class
and object methods are in camelCase, standalone functions are
underscore_separated. This seems to be pretty well established in the
PHP community now, and if you pick a different convention, then you will
be going against the tide of libraries you integrate with.

The core functions which follow neither rule include C-style
abbreviations like "strptime" which couldn't be automatically swapped to
either format, and complete anomalies like "nl2br". If you named those
functions as part of a consistent style, you would probably also follow
stronger naming conventions than Rasmus did when he named
"htmlspecialchars".

At the end of the day, integrating 3rd party code will always expose you
to their design decisions in all sorts of ways - whether they use
underscores is a pretty simple thing to remember compared to how they
structure dependencies, what patterns they expect you to use when
integrating / extending the code, etc.

Regards,

--
Rowan Collins
[IMSoP]

11 years ago by Rasmus Lerdorf — view source — reply

unread

The core functions which follow neither rule include C-style
abbreviations like "strptime" which couldn't be automatically swapped to
either format, and complete anomalies like "nl2br". If you named those
functions as part of a consistent style, you would probably also follow
stronger naming conventions than Rasmus did when he named
"htmlspecialchars".

Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.

-Rasmus

11 years ago by Rowan Collins — view source — reply

unread

This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.

Absolutely, and to make sure it's clear, I meant absolutely no offence
or criticism in mentioning it. If I ever invent a language that comes to
be used by millions, then just maybe I'd have the right to criticise. :)

I actually picked htmlspecialchars() as an example because I remembered
you using it as one at a conference. I guess I could have pointed out
that in its way there was a naming convention: pick names with different
lengths where possible - but I didn't want to drift off-topic.

My main point is that if we were to impose a new naming scheme on
existing functions, adding or removing underscores would be just the tip
of the iceberg.

--
Rowan Collins
[IMSoP]