[RFC] [DISCUSSION] Consistent Function Names

Hi all,

Hi Lester,

Good point!
I'll update documents so that main function is prefered name/function
to be
used.
This would be fine if all the users read the manual, and only the
manual. What about the thousands of books, tutorials, blog posts, Stack
Overflow q&as, etc, all mentioning the names and behaviour that have
been
around for 15 to 20 years? Not to mention the thousands of lines of
existing code which people will not only need to read and understand,
but
also contribute to without accidentally breaking compatibility with old
versions of PHP.
This is perhaps the key ...

Yasuo has at least now come on board over the IEEE standards but has
also spotted that because of allowing a little to much freedom in the
past some of the current guide lines do not marry with the well
established standards :(
I've updated the RFC to have IEEE names as well as other established
library function
names as valid names. We wouldn't have much problem having aliases for
it.
I think it would be useful.

One of my own personal gripes has always been that while some names are
consistent with the standard, the rules for adding names adopted at the
time wasn't? It is this which has created the problem and if there is
any reason to change things now it should be to follow the IEEE coding
style which is also followed by secondary libraries like gettext.

is_int should simply be isint in line with the IEEE standard but that
divergence of standards was not a good enough reason to avoid the
current 'inconsistencies' at the time?

I don't know how CONDING_STARNDARDS is made. Anyone remember
the discussion?

PHP has function names copied from C libraries at the beginning. Then
name with "_" became standard. Therefore, we have phpversion(), isset().
I remember empty() discussion whether it should be is_empty() or empty().
Shorter name is preferred and empty() is used. We chose
inconsistent names on occasions like StdClass::__set_state().

Having C library like name is not bad, but I think too many aliases are
better
to be avoided. Especially for basic functions. I'm not sure if it's good
for PHP
to have isstring(), isarray(), etc. It's one possibility though.

The bit I'm still unsure of here is not so much messing with some of the

fine detail of the procedural based functions, but the coding standard
that ACTUALLY applies at the object level. Using one naming standard for
ths area and a different one for an object version of the same set of
functions is equally confusing?

I agree. I wouldn't rush into.
If we change, we should change them right.

We have the implementation already.
http://php.net/arrayobject

I looked into the implementation. I'm surprised that it's overly
complicated.
It uses "array(hash)" and "object" for array storage for some reasons.
This
makes it difficult to reuse procedural implementation. We may do
something
for this issue.

One of the reasons I don't think it as caught on?
But the starting point here is naming methods in these objects and the
'assumed standard' seems to be camelCaseStyle rather than under_style ?
Again the horse has bolted since objects like http are now well
established with camelCaseStyle rather than following the C coding style
anyway.

The only question that needs answering first is just what standard ARE
we working to and what should that be to be consistent between
procedural and object models?

Function names without "" is better for camelCase methods. I agree.
Personally, I don't have any bad impression for having "" for procedural
functions while having camelCase for methods.

It's valid option to have camelCase for procedural functions' main name.
I don't mind removing "" from procedural functions much, but C library
names are not standardized well enough. (I mean naming convention
differs library to library) My current impression is having "" in names
and have PHP name would seem more consistent.

I guess this is the reason why CODING_STANDARDS is made like it
is now. We may introduce new procedural naming standard with
camelCase name that can keep consistency.

Thoughts?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi Rowan,

On Sun, Mar 8, 2015 at 8:31 AM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:

What? That's not the same thing at all. I'm pretty sure those
functions are deprecated *because* we have array callback forms,
so you can use call_user_func to call a method.

PHP has a well-defined definition of "callable", as used by
`is_callable()` and function parameter typehints, and literally
everywhere that wants a callback. Since there's no such thing as a
function or method pointer, that definition includes a string
identifying a plain function, and two array forms, [string,
string] and [object, string], representing static and instance
methods, respectively. You can't not accept those forms as a
callback parameter in one particular function just to make things
tidier.

I should have written "Let deprecate all array callbacks" by
document and raise deprecate error in PHP7.
Remove array callbacks in PHP 8.

In favour of what? We have no other way of telling a function expecting
a callback to use an existing method.

And why? Because one particular function signature you want to create
would be possible if "array" and "callback" were non-overlapping type
hints? Is there something wrong with having a function that explicitly
tells people it takes callbacks, rather than guessing based on the
arguments you pass in?

Regards,

--
Rowan Collins
[IMSoP]