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? > 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? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
