Hi all, On Sat, Mar 7, 2015 at 7:32 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 06/03/15 23:18, Yasuo Ohgaki wrote: > > Hi Lester, > > > > On Thu, Mar 5, 2015 at 8:46 PM, Lester Caine <les...@lsces.co.uk> wrote: > > > >> On 05/03/15 09:40, Rowan Collins wrote: > >>>>> > >>>>> 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 yohg...@ohgaki.net
