We're probably best off staying with the status quo and trying to keep a 
close look at any new modules which make it into the tree and modules which 
have been added since 4.0.4 (or maybe a small time before).
It doesn't make much sense to go back and break old names and it doesn't 
make lots of sense to create a zillion of aliases.I guess if there are some 
names which in particular need fixing because they are terrible (there 
might be some of these) then we should fix them on a per-function basis.
I am for uniform names but not if it's at the price of adding a zillion of 
aliases or at a price of making 50% of people's old scripts not work. I am 
also very much against compile-time options because I'd expect a script 
written in PHP and posted on some sites code exchange to work for everybody.


At 04:04 AM 3/1/2001 -0700, Zak Greant wrote:
>Phil wrote:
> > Ron - whose postings I normally agree with :-) - wrote:
>As do I :)
> > I know that Zak has been doing some experiments along these lines, but has
> > also been busy on other projects. Any news to report Zak?
>I now have less hair that I did before starting. ;)  Finding sensible
>consistent names for the function is somewhat of an undertaking.  I am still
>working on it....
>I have been twiddling away with a few ideas and have come to some
>Naming is broken.
>Points in case: defined, function_exists, isset and class_exists...
>We should have a set of standard verbs that we use for cases like this.  I
>would like to see something like:
>We can't agree
>No consensus on this issue can be reached.
>We seem to have several schools of thought on this issue.  Here are my
>bitter, narrow, soft-headed and sarcastic views on them:
>Deny the existence of a problem :)
>There is no problem with the function names. So stop yer whining or we'll
>make you use Damian Conway's Lingua::Romana::Perligata instead of PHP.
>Well, ok... there may be a problem, but I am not convinced of it.  And if
>there were a problem, we need a better way to fix it than has been yet
>Live in eternal fear of backwards compatibility :)
>When issues of function renaming arise, frighten all the little hackers with
>stories of how the villagers will rise against us if we break backwards
>compatibility with PHP 2.
>Refuse to relinquish old C function names :)
>At the first sign of any change to the function names, cling tightly to your
>'woogie' and begin to cry. They can't make you give up your woogie - why,
>you;'d rather shave off your beard and give up your suspenders than live
>life without your woogie.
>Bite off more than you can chew :)
>Attempt to swallow large issues in a single bite and end up choking on your
>wishful thinking.  Core developers stand around you and make bets on what
>color your face will turn before someone remembers the function name for the
>Heimlich manuever (is that apply_heimlich_manuever, heim, heimApp,
>windpipe_clear... or was it set_socket_blocking (FALSE)
>Expand the scope of the argument :)
>Expand the argument scope until it encompasses almost every aspect of the
>language. Wonder why everone else looks at you like you are a large
>Hamstring the discussion :)
>Ignore the thread til it looks like it is getting somewhere, then unload one
>crippling message and retreat from the ensuing carnage.
>Seriously, this is a bugger to resolve!  I don't think that there is a hope
>in hell on getting consensus on this issue.
>The only solutions I see are:
>Add an extra module that implements sane names.  This would be a
>compile-time option that is disabled by default. Include methods to
>translate scripts between the two naming scheme.  Include tools to make
>coding easier, including Hartmut's handy function looker-upper widget
>(basically, if you use an unknown function name, PHP attempts to recommend a
>proper function name for you to use.)
>In the off chance that we can get consensus, either:
>     Start a ground up rework of the language for PHP 5.  Audit the source
>code and fix the outstanding gremlins.  I suspect that this has about as
>much chance happening as most of us have of becoming male models.
>     Implement one of the moderate proposals that many of us have already
>Fork the codebase - start a variant called H_P_H (Hypertext
>Preprocessor::Hypocoristic) with sensible names ; )\
>In any case, it is 4 in the morning over here and I still have work to do.
>I hope that this makes some sense.
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to