Re: RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

RC>> "Accident" generally does not have a good meaning here Hmm... I guess I'm not so good in local slang. RC>> (AZ,USA)... while we (PHP) may not have a good naming schema for RC>> all functions, I think it is helpful for the PHP user base to be RC>> able to comprehend the use of a function based on the name. On its name, yes - but not on underscores in it. Do you really think anybody will remember/care for those underscores? RC>> Now, based on what I've seen from Stanislav's code, he's used to RC>> this nightmare, to thousands of include files where *one* typo RC>> annhilates an entire compile. But our users, our base, is not at Well, life's female canis familiaris. No naming scheme would resolve the problem that if you make typos it probably won't compile. RC>> the level of Stas. Some have never used anything else. Others RC>> came to PHP because it didn't have the [method nightmare|tag RC>> bondage| forced typing] of other languages. No computer language known to me fixes the errors for you. I doubt any would exist some 50 years from now. What's your point here? RC>> Yes, ctype *could* be prefixed with VGH45i97_*. But it wouldn't RC>> be very helpful. Yes. But who you ague with here? Certainly not me, since I never said anything like that. Whoever said that, I fully support you in disapproving his statements. RC>> skilled coders can differentiate between 89DEGU567S_open() and RC>> 89D3GU5675_open().. it's because new language adopters *can't* RC>> differentiate. I don't see how it proves that is_alpha is better than isapha. For unwashed masses, it's manual lookup anyway - they have no idea how it even _could_ be called. For people knowing C and descendants, it's a cookie (not http one, the pleasant one) - one more function they already know. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115