Re: conventionaboutfunction naming II

Ron Chmara wrote: > Jouni Ahto wrote: > > On Tue, 19 Dec 2000, Zak Greant wrote: > > > Also, there was some discussion a few months ago about normalizing all of > > > the function names. > > > We have a lot of functions that do not conform to the standard. IIRC, the > > > discussion on the phpdoc list was to create a conforming alias for each > > > non-conforming function and as time permits, document that the old names are > > > deprecated. Then perhaps next major release or two - PHP 5 or 6 -the old > > > names stop working. > > Just to note, one big problem will be the documentation. With one > > conforming to the rules and (one|two|three|...) non-conforming names, it's > > going to be a bit hard. Or at least a bit hard to use the documentation. > > That was actually one of the first things that introduced this issue. :-) Most > names may have one revision (three? havn't seen that yet). The doc list passed > around some ideas, it was also discussed on php-dev, and the current results > of those discussions are in there....(see below) > > > I > > haven't seen any good solutions in DocBook XML for this. Tagging something > > as <note>... In PHP ?.--?.?, this function foo_bar_create was called > > FooBarCreate ...</note><note>... In PHP ?.?.--?, this function > > FooBarCreate was called FooBar ...</note> isn't it. > > Only the current, official, name of the current, official, function will be > completely documented. The others are documented as deprecated variants on > the name.... > so the above is very close. It sure beats having a separate manual entry each for > FooBar, Foo_Bar, FoBar, or a different set of manual pages for each > change. This too, is part of the documentation... phpdoc/README. Hmmm... I should really learn how to read... > > PHP_FALIAS_WILL_BE_DEPRECATED_SOMEDAY(foo, bar [, ...]) > > PHP_FALIAS_WILL_BE_DEPRECATED_VERY_SOON(foo, bar [, ...]) > > PHP_FALIAS_WILL_BE_DEPRECATED_REALLY_SOON_NOW(foo, bar [, ...]) > > LOL! However, I think the code will probably "age" differently, where > somebody can just look through CVS for when it was aliased, if they > feel like deleting it is a really important task, and bring it up then... > However, in 3 years, chances are that many modules may be re-written > anyways, for other reasons (see oracle/oci8), so this isn't really > that critical of an issue, is it? True enough for a lot of the 'external' modules. However, I don't know how much change the core functions, like 'isset' will see... > Re: The prior dicusssion of Sept. 12: > The difficulty in handling the actual retiring (not just the "official" > deprecation of the usage) wasn't really concluded AFAICR, other than > "not right now, but later (maybe)", with an emphasis kept on compatibility. To > summarize that discussion, there were three general schools of thought: > > 1. Deprecate early, deprecate hard, cut out the old one entirely. > 2. Age it out gracefully, somehow. The "how" wasn't clearly defined. > 3. De-document it, but leave it usable, possibly forever. > > There was no concensus reached, other than informing current users that > function names were deprecated (via the manual) was good, and that > breaking lots of code at one time was a bad thing. I think that most > users expect that 2 major revs will mean some major changes (hence, > PHP 5, PHP 6) so function names from PHP 3 that are being "aged" may > be cut out then.... it doesn't actually _break_ anything to leave them > in there, though, does it? Perhaps this is something that the core developers could answer? What is the performance lost by maintaining a large number of aliases? Would it really be noticeable? --zak BTW Thanks for the summary Ron! -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net