Re: Resurrecting the Function Renaming Thread

waldschrott wrote: > I already walked through a number of extension and posted results here. > I still dislike that not all array functions begin with array_ (eg. the > older ones), perhaps we should create aliases here to and remove the old > ones from the documentation or move them elsewhere? Also, we should address problems with older function names like isset and strtr... In fact, I would vote that almost every function should receive this treatment. ie. trim > str_trim substr > str_substr However, I suspect that many people may not agree with me on this issue. :) The only real exceptions (IMHO) to this should be the most fundamental functions and constructs. I would not want to have to use functions like print_echo and print_print (or even more horrible, flow_do, flow_while and flow_if ;) [1] However, who knows - maybe a function called print_formatted would make a lot more sense than printf? With this issue, I would suggest that we not let it disrupt major work on renaming the obvious and more recent offenders. I would like to start correcting the more external modules very soon. We can decide what to do with the core stuff while we are working. :) [1] At some point, I am sure that someone will bring up the issue of using perl-like modules to resolve some of the naming issues. Note: I like some things about perl very much - behold my stupid and perl-like use of PHP's 'and' logical operator: $foo and $foo = 'bar'; # I am trying to break this shameful habit ;) Despite this odd proclivity on my part, I would be very much against using modules. Modules and their associated problems seem to confuse the heck out of new programmers. If someone really feels strongly about the issue, there are ways that experienced developers can employ to simulate the same functionality fairly simply - and all without inflicting uneccessary evils on unsuspecting new users. (Wow - I can sure shoot my mouth off - please take the above with a grain of salt - the word on issues like this can only really come from the core developers! :) [snip] > Separating them (deprecated functions) into a "deprecated" section in > the documentation is very important I think. That does make sense - and if they were in a separate section, this would allow us to leave it in for the benefit of developers updating old scripts. It would also make it very evident to users that the function they were looking at was deprecated. --zak