Re: [PHP-DEV] Woah
At 02:10 PM 9/9/2001 +0200, Sascha Schumann wrote: Cleaning up a language is a benefit worth paying in price for. How many millions of lines of C code had to be re-written when the ANSI standard was published? Exactly none. ANSI preserves most KR semantics and that won't change in the foreseeable future. I can only talk of ANSI C++. I was involved in a porting project from pre-ANSI C++ to ANSI C++ and lots of stuff broke :) I'm just saying this as a FYI. I'm too far behind my Email to comment on the thread itself. Andi -- 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]
Re: [PHP-DEV] Woah
On 11/09/01, Chuck Hagenbuch [EMAIL PROTECTED] wrote:
would be even happier if calling alias_function('gettext', '_') would simply
do nothing if _() already pointed to gettext(), but I won't quibble about
the function_exists() check.
What about a language construct:
function _ = gettext;
If we had this implemented during the compile phase of the engine,
wouldn't it shave a few cycles off the execution time?
OK, it looks a bit funny that way, so how about making
alias_function(_, gettext);
a language constuct (or with quotes around the args if you must).
Just wondering...
--Wez.
--
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]
Re: [PHP-DEV] Woah
Egon Schmid wrote: Wez Furlong wrote: So it's never going to collide with anything else You say that if you come across it and wonder what it does, the manual doesn't tell you what it is. Lets solve that by putting it in the manual. It is mentioned in the PHP manual. See http://php.net/gettext. yes, but if you know what _(...) is you don't have to read the gettext page, and if you don't know you won't figure it out from the manual unless you've read it al the way through and remember every single word in it. even searching for 'underscore' won't give you a clue ... We have a convention, not to document aliases as a function. This means _() is mentioned within the gettext() function. i thing we should at least, while not putting in extra pages for aliases, find a way to have them listed somehow and to make the URL shortcuts like http://php.net/_ work for them -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Woah
Joey Smith wrote: I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. now tell me how *that* isn't obscure if you happen to be looking at some piece of code (maybe due to an error message with line number) without recognising this statement at the top ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
RE: [PHP-DEV] Woah
I agree. I think this two pronged appoach is the best way to satisfy everyone. Let's do this alias thing, but lets also document _() for the sake of those people that have never heard of gettext but need to maintain the code. --Wez. The world needs more engineers BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
Re: [PHP-DEV] Woah
It is no more obscure than a #define in a C file, which is the way this construct is most commonly implemented...but, as I said, I would rather see [this]...than to see _() stay. I don't like it. But it is less offensive to me than _() is... On Tue, 11 Sep 2001, Hartmut Holzgraefe wrote the following to Joey Smith : Joey Smith wrote: I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. now tell me how *that* isn't obscure if you happen to be looking at some piece of code (maybe due to an error message with line number) without recognising this statement at the top ... -- 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]
Re: Fwd: Re: [PHP-DEV] Woah
Zeev Suraski wrote: Ken - see my point? :) I have seen it all along. I just do not think that removing it is better than leaving it forever but discouraging it. And you cannot say that 'ugliness is not a metric' for anyone except yourself. Multiple people have brought that aspect up, so obviously it matters to *them*. Please do not dismiss those inputs unless you think they do not count, in which case I suppose we should just accept that you are inflexible and consider your opinion better than anyone else's. :-D -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Zeev Suraski wrote: Did/do you use gettext in other languages? No If the answer to the latter, at least, is 'no' then I think the experience of people like Rasmus and Chuck -- who *do* use gettext a lot, and in other languages -- carries a helluva lot more weight than your speculation and that of other non-gettext-users. I respectfully disagree. The issue here isn't about people who use gettext. It's about those who don't. Eh? So you do not mind making a feature harder for the people who use it, just because it makes more sense to the people who do not? ??? Moral - the obscurity of such a feature should be determined by the general public, and *NOT* by the ones who use it. Okey, determine that it is obscure. Determining that and removing it are two different things. I do not mind if you label it as obscure; I *do* mind you, who never use it, making it much more difficult for the people who do. Live and let live, don't try to force people into your mould. Did you look at the deprecation method I suggested? Yes. It boils down to taking something away from your users. Now or later, that is still what it is doing. Your argument seems to be that _() is obscure for people who happen to come across it, or have to suddenly maintain something that uses it. The userland function solution does not change that. My opinion: let them deal with it. They are and probably will remain a minority compared to those who actually actively use it. How long has it taken you, one of the in-depth-est PHP developers, to notice this? The effort required for them to find out what it does, compared to that required by current users to change the way they work, seems very heavily weighted toward the latter. MHO, of course. When I encountered this whilst tech-editing PHP Essential Reference, my reaction was, 'Cool! What a low-impact way to do I18N!' And I kid you not, that is really how I felt, and feel. The problem with this whole discussion is that people are mixing two issues: (a) Is it an ok thing that _() is a PHP function I say that it is perhaps unfortunate, but okey. (b) What can we do about removing it That only comes up if people answer 'no' to (a). Hey, I am not a member of the PHP group. I am just a user. Never mind that I have been writing software for more than a quarter-century. You guys are going to do whatever you're going to do, and the only effect my differing opinion is likely to have is to piss everybody off. So I'll stop arguing and let you get on with it. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Chuck Hagenbuch wrote: Zeev: were it being added now, no, I wouldn't argue for it. My argument is based on it having been there for years and being in heavy use in some people's code. Likewise MHO. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Joey Smith wrote: Ken, I whole-heartedly apologize for my rude statments...it is simply a measure of my frustration with _() that led to me behave so poorly, and I hope you'll forgive me. Thank you for apologising. Forgiven. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
RE: [PHP-DEV] Woah
On 08/09/01, Cristopher Daniluk [EMAIL PROTECTED] wrote:
Again, as mentioned before, this is suitable:
function _($string) { return gettext($string); }
Yes, but if you use gettext on any large site, you will be using it a
helluva lot; and this would slow it down.
I would adopt this if the Zend Engine could optimize this away to be
either an inline function call or dynamically create an alias.
However, since I have already used this in hundreds of lines of code,
as have others for a long time now, I think we should stop talking about
_(); it's not going to acheive anything - we can't change it because of
BC.
--Wez.
--
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]
Re: [PHP-DEV] Woah
On 08/09/01, Zeev Suraski [EMAIL PROTECTED] wrote: At least give the user the option to decide whether he wants to pollute his namespace. At least give the code readers a chance to figure out what's going on by grepping the PHP source code. Sending them to the C source code or to debuggers is the old style thinking of PHP. Most new comers to PHP today have no C knowledge. The user gets the choice of polluting their namespace by compiling in the gettext extension. Are you really serious when you say that you want to deprecate _()?? Just think how many of the bigger guys will be affected and seriously pissed that their nicely localized enterprise application suddenly doesn't work or drops its performance several notches ? Yes, I know it's not nice, but it's the unnofficial standard. Lets think about this: _() is only there if you compile in the gettext extension. _() is recognized by all gettext users as being an alias for gettext() You say that _ should not be used for anything in the language or on it's own. So it's never going to collide with anything else You say that if you come across it and wonder what it does, the manual doesn't tell you what it is. Lets solve that by putting it in the manual. I don't think it's such a big deal. --Wez. -- 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]
Re: [PHP-DEV] Woah
On 08/09/01, James Moore [EMAIL PROTECTED] wrote:
I think that echo is used
a lot more so lets make echo aliased as ^(.) oh and perhaps we should
have sprintf as *() and dont forget while.. I bet perople get bored of
typing that so lets make it (conditional expreesion) { }
No, no, no, no! :-)
The people here arguing for the _() gettext alias are NOT suggesting that
we alias everything with insane single character aliases.
It's about _() being the standard for gettext. The gettext code processing
tools also use it. Yes I agree that to someone that hasn't used it before
it's confusing, but so what? Put it in the manual and the confusion goes
away.
I don't think deprecating it will make the problem go away: people will
still use it because a) all their other code uses it and b) thats the
way you do things with gettext c) A page full of the word gettext is
certainly harder for a person to parse and read the meaning of their
localized text than an inobtrusive _ character.
So, if we remove the falias people will still put their own in and all the
PHP code will end up looking the same so the net effect is that we have
slowed down the PHP code, added a function and not changed the readability
or namespace pollution.
So what exactly are we arguing about^H^H^H^H^H^H^H^H^H^H^H^H^H discussing
here? That _() is evil and should go, or that we definitely don't want
anything else like it in the future?
I think/hope that it is the latter.
If the purists have their way and remove the alias (even if it is a long
time away), then we can offer one of the following solutions:
1. Allow a way for PHP code to tell the zend engine that an identifier is
now a function alias.
2. Create a php config directive that allows you to do the same thing
3. Force the user to declare their function but have the zend engine
optimize the function call to call the aliased function.
I like the idea of the last option if you're into readability, although
the first two are likely to be a few cycles faster overall (there is no
need to parse the function call to setup that alias).
I still maintain that losing _() won't buy PHP anything, but agree that
we should not let any other single character alias creep in there.
--Wez.
--
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]
Re: [PHP-DEV] Woah
Wez Furlong wrote: Are you really serious when you say that you want to deprecate _()?? Just think how many of the bigger guys will be affected and seriously pissed that their nicely localized enterprise application suddenly doesn't work or drops its performance several notches ? Yes, I know it's not nice, but it's the unnofficial standard. Lets think about this: _() is only there if you compile in the gettext extension. _() is recognized by all gettext users as being an alias for gettext() You say that _ should not be used for anything in the language or on it's own. So it's never going to collide with anything else You say that if you come across it and wonder what it does, the manual doesn't tell you what it is. Lets solve that by putting it in the manual. a very big +1 from my side here -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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]
Re: [PHP-DEV] Woah
Quoting Wez Furlong [EMAIL PROTECTED]: 2. Create a php config directive that allows you to do the same thing -1. Config directives are a huge headache for people who distribute code (and for projects like PEAR). Let's not encourage adding more of them, when there are much better solutions... (yes, Wez, I know this wasn't your top choice) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Here's a functional alias_function call which duplicates a functions entry
in the global function table (ripped from APD with minor mods).
PHP_FUNCTION(alias_function)
{
zval **z_orig_fname, **z_new_fname;
zend_function *func, *dummy_func;
if( ZEND_NUM_ARGS() != 2 ||
zend_get_parameters_ex(2, z_orig_fname, z_new_fname) == FAILURE )
{
ZEND_WRONG_PARAM_COUNT();
}
convert_to_string_ex(z_orig_fname);
convert_to_string_ex(z_new_fname);
if(zend_hash_find(EG(function_table), Z_STRVAL_PP(z_orig_fname),
Z_STRLEN_PP(z_orig_fname) + 1, (void **) func) == FAILURE)
{
zend_error(E_WARNING, alias(%s, %s) failed: %s does not exist!,
Z_STRVAL_PP(z_new_fname), Z_STRVAL_PP(z_orig_fname),
Z_STRVAL_PP(z_orig_fname));
RETURN_FALSE;
}
if(zend_hash_find(EG(function_table), Z_STRVAL_PP(z_new_fname),
Z_STRLEN_PP(z_new_fname) + 1, (void **) dummy_func) == SUCCESS)
{
zend_error(E_WARNING, alias(%s, %s) failed: %s already exists!,
Z_STRVAL_PP(z_new_fname), Z_STRVAL_PP(z_orig_fname),
Z_STRVAL_PP(z_new_fname));
RETURN_FALSE;
}
if(zend_hash_add(EG(function_table), Z_STRVAL_PP(z_new_fname),
Z_STRLEN_PP(z_new_fname) + 1, func, sizeof(zend_function),
NULL) == FAILURE)
{
zend_error(E_WARNING, Failed to insert %s into EG(function_table),
Z_STRVAL_PP(z_new_fname));
RETURN_FALSE;
}
RETURN_TRUE;
}
- Original Message -
From: Wez Furlong [EMAIL PROTECTED]
To: James Moore [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Zeev Suraski
[EMAIL PROTECTED]
Sent: Monday, September 10, 2001 5:23 PM
Subject: Re: [PHP-DEV] Woah
On 08/09/01, James Moore [EMAIL PROTECTED] wrote:
I think that echo is used
a lot more so lets make echo aliased as ^(.) oh and perhaps we
should
have sprintf as *() and dont forget while.. I bet perople get bored of
typing that so lets make it (conditional expreesion)
}
No, no, no, no! :-)
The people here arguing for the _() gettext alias are NOT suggesting that
we alias everything with insane single character aliases.
It's about _() being the standard for gettext. The gettext code
processing
tools also use it. Yes I agree that to someone that hasn't used it before
it's confusing, but so what? Put it in the manual and the confusion goes
away.
I don't think deprecating it will make the problem go away: people will
still use it because a) all their other code uses it and b) thats the
way you do things with gettext c) A page full of the word gettext is
certainly harder for a person to parse and read the meaning of their
localized text than an inobtrusive _ character.
So, if we remove the falias people will still put their own in and all the
PHP code will end up looking the same so the net effect is that we have
slowed down the PHP code, added a function and not changed the readability
or namespace pollution.
So what exactly are we arguing about^H^H^H^H^H^H^H^H^H^H^H^H^H discussing
here? That _() is evil and should go, or that we definitely don't want
anything else like it in the future?
I think/hope that it is the latter.
If the purists have their way and remove the alias (even if it is a long
time away), then we can offer one of the following solutions:
1. Allow a way for PHP code to tell the zend engine that an identifier is
now a function alias.
2. Create a php config directive that allows you to do the same thing
3. Force the user to declare their function but have the zend engine
optimize the function call to call the aliased function.
I like the idea of the last option if you're into readability, although
the first two are likely to be a few cycles faster overall (there is no
need to parse the function call to setup that alias).
I still maintain that losing _() won't buy PHP anything, but agree that
we should not let any other single character alias creep in there.
--Wez.
--
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]
Re: [PHP-DEV] Woah
Wez Furlong wrote: So it's never going to collide with anything else You say that if you come across it and wonder what it does, the manual doesn't tell you what it is. Lets solve that by putting it in the manual. It is mentioned in the PHP manual. See http://php.net/gettext. We have a convention, not to document aliases as a function. This means _() is mentioned within the gettext() function. It is also listet as alias in Hartmuts function tables. In Hartmuts function tables the _() function is listed as italic character, but most people wouldn't regocnice the underscore character as italic character :) -Egon -- 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]
Re: [PHP-DEV] Woah
Wez Furlong wrote: What about delete()? Thats not even a real alias ? strpos and strchr? This dummy entry in the documentation was done by Kristian Köhntopp because most Windows lusers wouldn't find the real unlink() function. Sure it may be anoying some Unix users, but it is very helpfull for Windows users because they asked on mailing lists nearly daily, how can I delete a file. -Egon -- 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]
Re: [PHP-DEV] Woah
No, actually. I find syntax highlighting both annoying and distracting. I hope you're not terribly surprised by my answer. :) I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. On Mon, 10 Sep 2001, Wez Furlong wrote the following to Joey Smith : On 10/09/01, Joey Smith [EMAIL PROTECTED] wrote: I would love if every C developer in the world would stop using this. I doubt that's going to happen anytime soon...but at least I can voice my opinion here, what people at least hear me out, if they don't exactly *hear* me. :) I hear you, but sadly I don't think this will ever be changed :-( It's a bad idea. Always. No matter what language you are using. No matter what kind of library you are talking about. Making things this complex into such an easy thing to overlook is a good way to hurt and frustrate your users, and your fellow coders. Is gettext() *REALLY* that hard to type? I find that really, really hard to believe. It's not just the typing factor, it's the readability factor. Yes, gettext tells you what it does but it gets in the way. Do you use syntax highlighting in your code editor of choice? I do, and I find that I take in a lot of the syntactic information almost on a sublimininal level; my brain doesn't have to work as hard to understand the grammar so I can spend more time understanding what the code does. If I turn off the highlighting, or if it is not available (like running vi over telnet) it is that much harder to work with the code. To a certain extent shortening gettext() to _() is the same; think about it for a moment (you don't have to like it! ;-) If I gave you a piece of paper that had the word gettext tiled in the background with the code printed over the top you'd find it hard work to read the code. I know it's not exactly the same thing, but I'm just highlighting why I prefer _() in this case. The sheer quantity of gettext calls does make it unwieldy to use the full function name. --Wez. -- 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]
Re: [PHP-DEV] Woah
On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: This dummy entry in the documentation was done by Kristian K��opp because most Windows lusers wouldn't find the real unlink() function. Sure it may be anoying some Unix users, but it is very helpfull for Windows users because they asked on mailing lists nearly daily, how can I delete a file. Yeah, but the point is that despite the convention that we don't document aliases, we have exceptions. So why not document _()??? --Wez. -- 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]
RE: [PHP-DEV] Woah
I think that the point Zeev, Joey, I, and maybe one other person in the world are trying to make is not that _() is the best way to call gettext, our point is that being a nifty shortcut doesn't land its home in the heart of our fabulous language. We have a billion modules in php now, everything from cybercash to ircg (no offense to Sascha). What if EVERYONE who uses one of these arbitrary modules is used to _() in their preferred language? Of course you're going to say name one, but that would be you missing the point. We're being hypothetical, because as computer scientists, we know that the worst will always happen. We often ignore that fact, as in this case here (similarly with y2k). I think that I can summarize the viewpoints of my comrades as follows: 1. Yes, everyone who uses gettext expects _() to be there 2. Yes, its a good thing to make these people happy 3. Making them happy does not mean we need to risk confusion in our entire language. It also doesn't mean we give gettext people special treatment over some other module that may want _() for an equally good reason. 4. We (being people other than myself) came up with several naming conventions by which PHP should behave. These apply to functions, not to things like regexes and ?= as others have brought up. 5. It's not like removing _() from PHP blocks any future ability to use _() in code. The myth that people will have to change thousands of lines of code is patently false 6. Even C's gettext, the primo example of _ in action, DOES NOT BRING _ IN BY DEFAULT. It requires the DEVELOPER to introduce the alias via a #DEFINE. Even C, the mother of polluted, distasteful namespaces doesn't dare bring it in, and in fact in GNU Gettext's documentation, it states that doing so arbitrarily would not be good. 7. Plenty of alternatives have been suggested. Userspace functions were suggested but not liked because of the potential for apocalyptic performance losses that singlehandedly drives even the smallest i18n site into the ground in a ball of fiery mass (end of sarcasm). Still, the option of introducing runtime function aliases and/or compiler directives was brought up. I personally prefer this solution, its not a bad idea for PHP to have anyway, and gives users a ONE LINE solution, while giving the rest of PHP, the overwhelming majority mind you, a more consistent language. Clearly, no one loses in this scenario. The small chunk who use gettext make a one line change. Performance is not affected. Conventions are satisfied. Everyone goes home happy. What's the problem? Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 6:00 PM To: Joey Smith Cc: Wez Furlong; PHP Developer List Subject: Re: [PHP-DEV] Woah On 10/09/01, Joey Smith [EMAIL PROTECTED] wrote: I would love if every C developer in the world would stop using this. I doubt that's going to happen anytime soon...but at least I can voice my opinion here, what people at least hear me out, if they don't exactly *hear* me. :) I hear you, but sadly I don't think this will ever be changed :-( It's a bad idea. Always. No matter what language you are using. No matter what kind of library you are talking about. Making things this complex into such an easy thing to overlook is a good way to hurt and frustrate your users, and your fellow coders. Is gettext() *REALLY* that hard to type? I find that really, really hard to believe. It's not just the typing factor, it's the readability factor. Yes, gettext tells you what it does but it gets in the way. Do you use syntax highlighting in your code editor of choice? I do, and I find that I take in a lot of the syntactic information almost on a sublimininal level; my brain doesn't have to work as hard to understand the grammar so I can spend more time understanding what the code does. If I turn off the highlighting, or if it is not available (like running vi over telnet) it is that much harder to work with the code. To a certain extent shortening gettext() to _() is the same; think about it for a moment (you don't have to like it! ;-) If I gave you a piece of paper that had the word gettext tiled in the background with the code printed over the top you'd find it hard work to read the code. I know it's not exactly the same thing, but I'm just highlighting why I prefer _() in this case. The sheer quantity of gettext calls does make it unwieldy to use the full function name. --Wez. -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc
RE: [PHP-DEV] Woah
At least can we create a reference? User wants to know what the hell _ is, he goes to www.php.net/_ and gets an answer - of course that may be a problem since _ is such a goofy url, most people will assume it doesn't work. Another reason _ is bad! :) Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 6:58 PM To: Egon Schmid Cc: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Woah What about delete()? Thats not even a real alias ? strpos and strchr? Let's put in the alias for _(); it removes the wtf factor. --Wez. It is mentioned in the PHP manual. See http://php.net/gettext. We have a convention, not to document aliases as a function. This means _() is mentioned within the gettext() function. It is also listet as alias in Hartmuts function tables. In Hartmuts function tables the _() function is listed as italic character, but most people wouldn't regocnice the underscore character as italic character :) -Egon -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
RE: [PHP-DEV] Woah
Seems like we have a trend of conventions and their exceptions in PHP :) Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 8:21 PM To: Egon Schmid Cc: Wez Furlong; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Woah On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: This dummy entry in the documentation was done by Kristian Km9m4opp because most Windows lusers wouldn't find the real unlink() function. Sure it may be anoying some Unix users, but it is very helpfull for Windows users because they asked on mailing lists nearly daily, how can I delete a file. Yeah, but the point is that despite the convention that we don't document aliases, we have exceptions. So why not document _()??? --Wez. -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
Re: [PHP-DEV] Woah
Wez Furlong wrote: On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: This dummy entry in the documentation was done by Kristian K��opp If you don't use the ISO 8859-1 language I have to rewrite the name with: Kristian Koehntopp. because most Windows lusers wouldn't find the real unlink() function. Sure it may be anoying some Unix users, but it is very helpfull for Windows users because they asked on mailing lists nearly daily, how can I delete a file. Yeah, but the point is that despite the convention that we don't document aliases, we have exceptions. So why not document _()??? The _() alias is no function. If someone build-in gettext, he or she should read the gettext documentation. The manual can be only a better function reference and if every alias would have a description just like the real functions, newbies will never find the functions to use. So let the aliases mentioned at the pages where the real functions are described. Look at http://php.net/mysql functions to get the point. There are many old function names, which cannot deprecated, because this functions are now aliases. Out of the curiosity, there have been a function (couldn't find it yet) which was named rtfm(). This function appears in a German book about PHP and it was implemented as a real function and was properly documented. If you are interested in the not so long history of the rtfm() function, search in the PHP-DEV mailing list archive. -Egon PS1: I'm editing openssl to fix some prototypes, so don't touch it in the next couple of minutes. PS2: Sorry, will start again after an update. Please be patient until you see my commit. -- 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]
RE: [PHP-DEV] Woah
On 11/09/01, Cristopher Daniluk [EMAIL PROTECTED] wrote: Still, the option of introducing runtime function aliases and/or compiler directives was brought up. I personally prefer this solution, its not a bad idea for PHP to have anyway, and gives users a ONE LINE solution, while giving the rest of PHP, the overwhelming majority mind you, a more consistent language. Clearly, no one loses in this scenario. The small chunk who use gettext make a one line change. Performance is not affected. Conventions are satisfied. Everyone goes home happy. What's the problem? There isn't one (as I have been saying all along). But it doesn't really change the fact that code that uses gettext will still have _() everywhere, and we will still have the problem of people saying wtf does _() mean? I can't find it in the manual?? which is the basis of this whole argument. Let's do this alias thing, but lets also document _() for the sake of those people that have never heard of gettext but need to maintain the code. --Wez. The world needs more engineers -- 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-DEV] openssl (was Re: [PHP-DEV] Woah)
On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: PS1: I'm editing openssl to fix some prototypes, so don't touch it in the next couple of minutes. PS2: Sorry, will start again after an update. Please be patient until you see my commit. Too late... I'm done for now though. --Wez. -- 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]
Re: [PHP-DEV] Woah
On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: The _() alias is no function. If someone build-in gettext, he or she should read the gettext documentation. The manual can be only a better function reference and if every alias would have a description just like the real functions, newbies will never find the functions to use. So why don't we have an alias index? Surely we can autmatically generate such a list and just have the aliases link to the preferred functions? Out of the curiosity, there have been a function (couldn't find it yet) which was named rtfm(). This function appears in a German book about PHP and it was implemented as a real function and was properly documented. If you are interested in the not so long history of the rtfm() function, search in the PHP-DEV mailing list archive. IIRC, it was Hartmut's baby but it got voted out. I didn't realize it was publicized in a book :) --Wez. -- 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]
Re: [PHP-DEV] Woah
On Mon, 10 Sep 2001, Joey Smith wrote: The point that *I* have been trying to get at is that this has *ALWAYS* been a bad idea, no matter what langague you are using. You all talk an awful lot about how _ decreases the contextual overhead. What I'm trying to express is that THIS IS BAD! gettext() is deep magic. When you are doing deep magic, every single thing you can do to make people MORE aware of what that magic relates to is a GOOD THING. I would love if every C developer in the world would stop using this. I doubt that's going to happen anytime soon...but at least I can voice my opinion here, what people at least hear me out, if they don't exactly *hear* me. :) It's a bad idea. Always. No matter what language you are using. No matter what kind of library you are talking about. Making things this complex into such an easy thing to overlook is a good way to hurt and frustrate your users, and your fellow coders. Is gettext() *REALLY* that hard to type? I find that really, really hard to believe. Sorry, I know I'm descending once again, but I have lost quite a bit of time trying to figure out what _ was (in C, not in PHP). I want to save others that pain and frustration if at all possible. It's a bad idea *to implement it in the language*, yes. It's a bad idea to implement this in the language for precisely the reasons that have been detailed here: it would be difficult to track down in the documentation (or header files), and it would clutter the language's namespace inappropriately. It's also against PHP's naming standards. But it's arrogant in the extreme to claim that it's always a bad idea for *anyone* to use such a convenience name. The practices of individual C programmers working on projects not related to PHP, or of programmers writing internationalized web apps, should not be at issue here, and I'm opposed to any measure which attempts to restrict the programmer's freedom in this regard. This includes the notion of removing _() without offering a suitable replacement mechanism that has comparable overhead both in the writing of the code and the running of it. Like it or not, the low overhead this gettext convention imposes on authors of C programs *has* contributed to its widespread adoption. I think a lesser solution in PHP is a disservice to the international community, and a terrible thing to do in the name of language purity. So I'm all for removing _() from the gettext extension... but I think the people who are so eager for this have a responsibility to make sure PHP has a good option for user-aliasing of functions in place before it goes away. Steve Langasek postmodern programmer -- 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]
Re: [PHP-DEV] Woah
Wez Furlong wrote: On 11/09/01, Egon Schmid [EMAIL PROTECTED] wrote: The _() alias is no function. If someone build-in gettext, he or she should read the gettext documentation. The manual can be only a better function reference and if every alias would have a description just like the real functions, newbies will never find the functions to use. So why don't we have an alias index? Surely we can autmatically generate such a list and just have the aliases link to the preferred functions? To automatically generate lists of functions and/or a separate alias list is no problem. The problem is the alphabetically sorting of lists with the current DSSSL stylesheets. I hope Hartmut or Jouni will have enough free time to play with it. Out of the curiosity, there have been a function (couldn't find it yet) which was named rtfm(). This function appears in a German book about PHP and it was implemented as a real function and was properly documented. If you are interested in the not so long history of the rtfm() function, search in the PHP-DEV mailing list archive. IIRC, it was Hartmut's baby but it got voted out. I didn't realize it was publicized in a book :) No, it was Peter Petermann's baby. He was one of the technical reviewers of a German book about PHP. We have here in Stuttgart a verg big and great PHP user community and so we have been informed, that Peter made his best joke in his life and wrote the nonexistent rtfm() function into this book. Late evening, Hartmut made a skeleton of that function with his notebook and checked it some days later in and provided the proper documentation. The rest of this story is history. This was the first case in the history of PHP that a function was described before the code existed. (There may be a formating code in the date functions, that is documented but not coded.) -Egon -- 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]
Re: [PHP-DEV] Woah
At 01:30 11-09-01, Egon Schmid wrote: Wez Furlong wrote: So it's never going to collide with anything else You say that if you come across it and wonder what it does, the manual doesn't tell you what it is. Lets solve that by putting it in the manual. It is mentioned in the PHP manual. See http://php.net/gettext. There's a *big* difference between mentioning it in the documentation, and having it documented. A function being documented has to mean that if I don't know what it is, I can look it up in the manual. This is *NOT* true for _(). You can say it's mentioned in the documentation, but it's certainly not documented. Zeev -- 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]
Re: [PHP-DEV] Woah
Oh yummy, we have delete()?! There goes our delete operator, but hey, what a nice little messy namespace do we have! It's gotta be worth it, it's so much shorter than delete_file() :) Zeev At 02:10 11-09-01, Egon Schmid wrote: Wez Furlong wrote: What about delete()? Thats not even a real alias ? strpos and strchr? This dummy entry in the documentation was done by Kristian Köhntopp because most Windows lusers wouldn't find the real unlink() function. Sure it may be anoying some Unix users, but it is very helpfull for Windows users because they asked on mailing lists nearly daily, how can I delete a file. -Egon -- 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]
Re: [PHP-DEV] Woah
At 04:37 11-09-01, Egon Schmid wrote: To automatically generate lists of functions and/or a separate alias list is no problem. The problem is the alphabetically sorting of lists with the current DSSSL stylesheets. I hope Hartmut or Jouni will have enough free time to play with it. Guys, Please make sure you understand that there's no such thing as aliases before you start working on that mini-project. There's only one type of entries in the PHP function namespace, and that's functions. There's no such thing as 'an alias'! Functions can be aliases to each other, but in such a case, they're completely (100.0%) equal to each other. It's similar to the way inodes and hard links work in UNIX filesystems. The way to go that truly best describes reality would be: - Documenting all non-deprecated functions, period. That includes FALIAS's just as it includes FUNCTION's. - Having a manually edited list of deprecated functions. Note that as far as _() goes, it clearly falls in the first category. Meaning that as long as it pollutes the global namespace and not deprecated, it should be documented in its own right. Zeev -- 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]
Re: [PHP-DEV] Woah
Quoting Joey Smith [EMAIL PROTECTED]: I would rather see something to the effect of use strict; (as in perl) that can be defined (per site/directory/namespace/SOMETHING...) to mean use gettext on all calls to print than to see _() stay. That would not provide the same functionality - you don't always want to print the internationalized string. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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-DEV] delete (was: Re: [PHP-DEV] Woah)
Quoting Zeev Suraski [EMAIL PROTECTED]: Oh yummy, we have delete()?! Zeev: in this case, you can relax. From http://www.php.net/manual/en/function.delete.php: This is a dummy manual entry to satisfy those people who are looking for unlink () or unset() in the wrong place. It's not actually in the namespace in any capacity whatsoever. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Quoting Steve Langasek [EMAIL PROTECTED]:
So I'm all for removing _() from the gettext extension... but I think the
people who are so eager for this have a responsibility to make sure PHP has a
good option for user-aliasing of functions in place before it goes away.
I think if something like this had been suggested in the first place, instead
of the all-out annihilate _() warfare that took place (and yes, I am guilty of
responding in kind), we might have had a much shorter discussion. Something to
consider for the future. :)
I would be happy with this kind of solution (removing _() after there is a user-
space alias_function() call which can create a new name for a PHP function). I
would be even happier if calling alias_function('gettext', '_') would simply do
nothing if _() already pointed to gettext(), but I won't quibble about the
function_exists() check.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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]
Re: [PHP-DEV] delete (was: Re: [PHP-DEV] Woah)
*Phew* :) At 06:18 11-09-01, Chuck Hagenbuch wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: Oh yummy, we have delete()?! Zeev: in this case, you can relax. From http://www.php.net/manual/en/function.delete.php: This is a dummy manual entry to satisfy those people who are looking for unlink () or unset() in the wrong place. It's not actually in the namespace in any capacity whatsoever. :) -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Cleaning up a language is a benefit worth paying in price for. How many millions of lines of C code had to be re-written when the ANSI standard was published? Exactly none. ANSI preserves most KR semantics and that won't change in the foreseeable future. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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]
Re: [PHP-DEV] Woah
Uhm, no. Read my message again, it actually makes sense. At 14:56 09-09-01, Jani Taskinen wrote: Does this mean we can forget namespaces then? Is this where we have come to: blackmail ? --Jani On Sat, 8 Sep 2001, Zeev Suraski wrote: Fine. Let it be noted that I oppose going forward with any other clean-up of the language namespace before this bug goes away. If we don't clean the obvious ones, we might as well keep in everything. (a very disappointed) Zeev At 15:51 08-09-01, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 09:13 08-09-01, Andrei Zmievski wrote: At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. Disappointment isn't exactly the metrics here. People who migrate from other languages will be disappointed not to find all sorts of things they're used to from their old languages, but it has never been a reason to obscure PHP. _() has no room in PHP's naming convention. There's a small downwards compatibility issue (it's not advertised very promptly), so we should deprecate it just like we deprecate and have deprecated other functions in the past. Hey, let's just leave it, please. There's a zillion people who use this now, it's what they expect if they have used gettext before. It's been here for 2.5 years, it hasn't bothered anyone until now, and I don't think removing it would be anything less than counter- productive. Removing it would only make people alias _ to gettext themselves, net result being i18n'ed code running slower. It's not like we're going to add more single-character aliases, so I don't buy the feature creep argument either. L_A! (leave _ alone!) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
Re: [PHP-DEV] Woah
At 16:57 09-09-01, George Schlossnagle wrote: Replaced with a call to strstr and function declaration placed ahead of usage (althoough I disagree about how much faster this will make it. I only declare the function once and loop it, so whether do_bind_function_or_class is called on it during compile or once during execution should be a minimal difference): It generates completely different code. Zeev -- 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]
RE: [PHP-DEV] Woah
Let's just make the supposition for a second that you're right, that the
difference between calling a userspace function over an internal function is
going to create phenomenal decreases in overall execution time. The
implication I believe you give is that over an amortized amount of time,
execution speed between calling a userland function and internal function
will be approximately 2x. This is just mind boggling! Sure, there's roughly
twice the work to call a user function wrapper compared to calling the
internal. There's also the loss in parsing. However, do not make the fatal
mistake of assuming that twice the cost of an operation translates to twice
the cost of a process, or for that matter, even a negligible cost increase.
PHP would not, and I can't make this clear enough, would NOT be a viable
option in the market if the performance loss in real world scenarios from
simply entering into a function was that great. I'd venture (these are
SWAGs) to say that a single call to preg_replace does over 500x more machine
instructions than calling a userland function. I bet the gettext call
itself, which is the focal point of this discussion, does 50x more machine
instructions, than the function call that's wrapping it. If you look at it
on a microcosmic sense, there is a clear and real difference, but when you
analyze on a macro level, you clearly can't argue there is a performance
loss worth caring about. It's just childish and foolish and arguing it makes
you look truly foolish. If you don't believe that, imagine for a tenth of a
second that you're right, and think about the implications.
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: George Schlossnagle [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 09, 2001 9:57 AM
To: Zeev Suraski
Cc: [EMAIL PROTECTED]; 'Chuck Hagenbuch'; 'PHP Developer List'
Subject: Re: [PHP-DEV] Woah
Replaced with a call to strstr and function declaration placed ahead of
usage (althoough I disagree about how much faster this will make it. I
only declare the function once and loop it, so whether
do_bind_function_or_class is called on it during compile or once during
execution should be a minimal difference):
9:43:36(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/strstr.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
1.140u 0.040s 0:02.02 58.4% 0+0k 0+0io 568pf+0w
9:43:40(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/b.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
2.350u 0.000s 0:02.35 100.0%0+0k 0+0io 296pf+0w
and with preg_match:
9:50:05(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/preg_match.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
1.520u 0.000s 0:01.51 100.6%0+0k 0+0io 303pf+0w
9:50:10(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/gpreg_match.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
2.880u 0.010s 0:02.88 100.3%0+0k 0+0io 304pf+0w
I realize these are still relatively simple functions, but the point of
this excercise is demonstrate the inherent speed differences between
internal and userland functions, whihc I think it does. Also 'simple'
functions are (totally my supposition, based on my experience) usually
the functions people use heavily inside there own code.
On Sunday, September 9, 2001, at 03:25 AM, Zeev Suraski wrote:
Substituting your favourite function for strlen() will probably not
yield similar results, though. strlen()'s implementation takes
virtually no time.
Also, try defining gstrlen() before you use it. It'd be much faster.
At 05:58 09-09-01, George Schlossnagle wrote:
Benchmarking the execution time for a single function call by making a
page and request it via b is a pretty flawed method. While it may
show that a single aliased call to gettext() doesn't change the
execution time of a script by much, it does not say anything about the
relative times for execution of a specific function. You should call
the function in a type loop and average over many executions. Here's
a sample you can try:
strlen.php:
?
$a = 'blah';
while($i 10) {
$b = strlen($a);
$i++;
}
?
gstrlen.php:
?
$a = 'blah';
while($i 10) {
$b = gstrlen($a);
$i++;
}
function gstrlen($str) {
return strlen($str);
}
?
22:54:00(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/strlen.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
0.840u 0.010s 0:00.85 100.0%0+0k 0+0io 293pf+0w
22:54:17(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/gstrlen.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
1.950u 0.010s 0:01.95 100.5%0+0k 0+0io 295pf+0w
Re: [PHP-DEV] Woah
Using obscure single character operators is simply something that we don't
do in PHP, it's totally inconsistent with the language.
You know I hate magic more than most. I have lobbied against it forever.
However, sometimes you need to conform with the underlying 3rd-party
mechanism you are connecting to.
Regular expressions are butt-ugly and full of magic. I'd love to
deprecate regular expressions and tell everyone to use a better mechanism
for string matching and manipulation. The LDAP reverse-polish query
format is also butt-ugly and non-intuitive, but people who have been doing
LDAP for years are quite fluent in it.
At the function level, strlen(), strchr(), strcmp(), strtok(), etc... are
all inconsistent with the PHP function naming standard. They should
logically be str_len(), str_chr(), str_tok()... or perhaps
string_length()... We don't do this because it would drive people very
familiar with the underlying API we copied crazy.
Having no efficient way to use _() would drive people very familiar with
gettext crazy because everywhere else they have used gettext they could
use this syntax. There are even gettext pre-processors that are keyed on
_(...) and go in and do static replacements of this text.
This doesn't mean I agree with the magic _() function, but until we have
some sort of efficient run-time function aliasing mechanism like they do
in Python, removing _() and telling people to create a user-space function
that calls gettext() is not going to make the gettext using people very
happy with us.
The way this was solved in Python is that they have a gettext.install
method which creates the _() function in the builtin namespace. The
function is only present once this install method is called on the gettext
object. See http://www.python.org/doc/2.1/lib/node187.html
Python has a second gettext API which is not as powerful and thus not used
as often and the typical usage of that is:
import gettext
_ = gettext.gettext
print _('blah blah')
ie. they use user-space function aliasing to create the _() function.
The thing to realize here is that _() is everywhere. Everything you read
about gettext will refer to _(), so people who want to use the PHP gettext
extension are going to want to use _(). There is no way around that. How
many hoops we force people to jump through to get there is the only real
question. We can't go back in time and change this convention. It's
there and we need to deal with it.
Now, ff this worked in PHP it would be an option:
define(_,gettext);
_(blah);
Or if there was a way to call a function like gettext_init() or maybe just
make it part of textdomain() or bindtextdomain() and have it dynamically
add the _ alias it would also be a good option. This doesn't seem
impossible actually.
I don't like the idea of forcing people to do:
function _($str) { return gettext($str); }
Since this is a function that will be called for every single string that
is output from an application, it is a function that will be called dozens
of times on every request. Adding the overhead of a user-space wrapper
call is irritating.
-Rasmus
--
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]
Re: [PHP-DEV] Woah
Zeev Suraski wrote: At 05:40 08-09-01, Chuck Hagenbuch wrote: It's the kind of thing that gets used a lot in HTML, where otherwise there wouldn't be a function call at _all_ - just static text. Replacing gettext() with _() in this case actually does improve readability, in my opinion. That's exactly what I said - there are several other functions/operators/labels which are used a lot and repeatedly, and we never made any exceptions as far as clarity goes. _() is not documentated as function because it is an alias. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php That's unfortunate. IMHO, it should be phased out. No, that would be the worst case you can do now, since _() have been there since PHP 3.0.7. Look at the first character in: http://www.zugeschaut-und-mitgebaut.de/php or http://zend.com/phpfunc in the alphabetical lists for PHP 3 and 4. Sure you can't see on most monitors that the single character '_' is slanted and this means it is an alias. Exceptions in php extensions have been made before where the extension mirrors the c library exactly, in order to not confuse people familiar with the library. This is another one of those cases - people familiar with gettext will be very confused if _() doesn't work the way they expect it to. You're talking about exceptions in the naming convention? Well, the more accurate way to describe it is that originally, modules tried to copy the low-level API function names 1::1. Only at a later stage we started to strive towards a standard naming convention. Today, when adding new functionality, the low level API function names play no role, and the functions are named using the PHP naming convention. We explicitly decided that in the lengthy discussion about function naming convention that took place half a year ago or so. There was no clear decision as to what to do with the existing functions that are named after their low-level counterparts. To remove _() as alias is IMHO a bad idea. It would be better to use new function names for the agreed function naming convention and make the current function names an alias. The performance decrease would IMHO less than the performance increase by switching to lowercase function names. At any rate, this is not the kind of exception I was talking about. _ includes 0.0 information about what it does, and unless you know exactly what it does, you're lost. It's not an issue of shortening words, or neglecting to put underscores between words. Not only do you not stand a chance understanding what you're reading without looking at documentation, but you also have absolutely no way of finding what this does if you actually look it up in a manual. Only gettext() is documented and not _(). For the underscores between words in function names, compare the mysql functions with the pgsql function names. This is really annoying if you switch from mysql to pgsql and have to look up the correct function names, because you cannot only substitute the prefix mysql_ to pg_. -Egon -- 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]
Re: [PHP-DEV] Woah
Rasmus Lerdorf wrote: reuse. We can get back to the idea of letting people define % as htmlspecialchars(), You can do that in PHP? How? You can't. You missed the dripping sarcasm. Well, I was torn between accepting it as sarcasm, and getting hints on how to accomplish it :) Totally impossible? Emile -- 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]
Re: [PHP-DEV] Woah
At 09:13 08-09-01, Andrei Zmievski wrote: At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. Disappointment isn't exactly the metrics here. People who migrate from other languages will be disappointed not to find all sorts of things they're used to from their old languages, but it has never been a reason to obscure PHP. _() has no room in PHP's naming convention. There's a small downwards compatibility issue (it's not advertised very promptly), so we should deprecate it just like we deprecate and have deprecated other functions in the past. Egon - what you said about the documentation is not something that is really viewable from an end user's point of view. If you look at the manual, you don't see it. If you look at the PHP function list, you see a function with no prototype and no documentation. In short, unless you happened to stumble upon it reading the documentation of gettext() - you have no idea it exists. If we can't deprecate a horrible name like this, I'm not sure why we held this huge function naming convention discussion back then. _() is a mistake that we can fix in a major version. Again, by deprecating it now, the immediate action would be removing any reference to it from the documentation (the very little there is). There are a hell of a lot PHP users to come than there are existing users of PHP, so we might as well limit the scope of the problem. We can also advertise that this function will not be staying with us in the future, and that people should use gettext() instead. We can add an E_NOTICE to it, which would make fixing it a trivial single command. When we actually remove this alias can be determined in the future. Zeev -- 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]
Re: [PHP-DEV] Woah
At 09:36 08-09-01, Rasmus Lerdorf wrote:
Using obscure single character operators is simply something that we don't
do in PHP, it's totally inconsistent with the language.
You know I hate magic more than most. I have lobbied against it forever.
Well, you did in certain occasions, but you encouraged certain degrees of
magic in the past.
However, sometimes you need to conform with the underlying 3rd-party
mechanism you are connecting to.
Not really. You only have to conform if you believe that PHP is not a
standalone language. You're also assuming that most of PHP's userbase has
C background, which is usually not true. Among those coming from C
background, usually they have a limited one, and would not be used to
gettext() aliases.
Regular expressions are butt-ugly and full of magic. I'd love to
deprecate regular expressions and tell everyone to use a better mechanism
for string matching and manipulation. The LDAP reverse-polish query
format is also butt-ugly and non-intuitive, but people who have been doing
LDAP for years are quite fluent in it.
Regular expression are butt-ugly by definition. You can either learn them
or not learn them. It's kinda like SQL. I'm not sure why you're failing
to see the fundamental difference between a function that is complex and
perhaps requires prior knowledge, and an entry that obscures the
*namespace* of PHP.
When I see ereg_replace(), I can go and learn about regular expressions.
When I see _(), I don't have the faintest clue what the heck it is. If I
even figure out that this is a function (it sure as hell doesn't look like
one):
(a) Consult the manual (won't do)
(b) Consult the function table (won't do)
If I don't, I can either read the source code or start up a debugger.
At the function level, strlen(), strchr(), strcmp(), strtok(), etc... are
all inconsistent with the PHP function naming standard. They should
logically be str_len(), str_chr(), str_tok()... or perhaps
string_length()... We don't do this because it would drive people very
familiar with the underlying API we copied crazy.
Again, there's a fundamental difference. I don't want to go back to the
discussion we had about function naming, but I don't see how you can
compare strlen() and _(). The differences in no particular order:
(a) Most people with limited English knowledge will be able to get a fair
understanding of what strlen() is, something which can't be said about _()
(b) strlen() looks like a function, and is documented like a function.
It's not a Good Thing that it's not following the PHP naming convention,
but as I said yesterday - PHP didn't have a naming convention to begin
with, it was born at a later stage. _() is not in *any* naming
convention. If any, it violates our (several months old) guideline that
only internal language-level functions should begin with an underscore.
Having no efficient way to use _() would drive people very familiar with
gettext crazy because everywhere else they have used gettext they could
use this syntax. There are even gettext pre-processors that are keyed on
_(...) and go in and do static replacements of this text.
Think about it. The only (or at least main) reason you're under this
assumption is because you're used to it. There are functions/names that
are used a hell of a lot more often than gettext(). And yet, we didn't
come up with C{foo} instead of $_COOKIE[foo] just to save
keystrokes. And we both know, this won't drive people away from using cookies.
gettext() is a short name. It's short and yet descriptive enough to give
readers a general understanding of what it does, something that they can
extend by reading the manual.
This doesn't mean I agree with the magic _() function, but until we have
some sort of efficient run-time function aliasing mechanism like they do
in Python, removing _() and telling people to create a user-space function
that calls gettext() is not going to make the gettext using people very
happy with us.
Cris showed a trivial way of doing that, if users actually want to do
it. function _($str) { return gettext($str); }. You don't need any new
mechanisms or magic to do this.
At least give the user the option to decide whether he wants to pollute his
namespace. At least give the code readers a chance to figure out what's
going on by grepping the PHP source code. Sending them to the C source
code or to debuggers is the old style thinking of PHP. Most new comers to
PHP today have no C knowledge.
Zeev
--
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]
Re: [PHP-DEV] Woah
At 10:24 08-09-01, Emiliano wrote: Well, I was torn between accepting it as sarcasm, and getting hints on how to accomplish it :) Totally impossible? Totally. Zeev -- 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]
Re: [PHP-DEV] Woah
[Zeev Suraski [EMAIL PROTECTED]] At 09:13 08-09-01, Andrei Zmievski wrote: At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. Disappointment isn't exactly the metrics here. People who migrate from other languages will be disappointed not to find all sorts of things they're used to from their old languages, but it has never been a reason to obscure PHP. _() has no room in PHP's naming convention. There's a small downwards compatibility issue (it's not advertised very promptly), so we should deprecate it just like we deprecate and have deprecated other functions in the past. Hey, let's just leave it, please. There's a zillion people who use this now, it's what they expect if they have used gettext before. It's been here for 2.5 years, it hasn't bothered anyone until now, and I don't think removing it would be anything less than counter- productive. Removing it would only make people alias _ to gettext themselves, net result being i18n'ed code running slower. It's not like we're going to add more single-character aliases, so I don't buy the feature creep argument either. L_A! (leave _ alone!) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
Re: [PHP-DEV] Woah
Fine. Let it be noted that I oppose going forward with any other clean-up of the language namespace before this bug goes away. If we don't clean the obvious ones, we might as well keep in everything. (a very disappointed) Zeev At 15:51 08-09-01, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 09:13 08-09-01, Andrei Zmievski wrote: At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. Disappointment isn't exactly the metrics here. People who migrate from other languages will be disappointed not to find all sorts of things they're used to from their old languages, but it has never been a reason to obscure PHP. _() has no room in PHP's naming convention. There's a small downwards compatibility issue (it's not advertised very promptly), so we should deprecate it just like we deprecate and have deprecated other functions in the past. Hey, let's just leave it, please. There's a zillion people who use this now, it's what they expect if they have used gettext before. It's been here for 2.5 years, it hasn't bothered anyone until now, and I don't think removing it would be anything less than counter- productive. Removing it would only make people alias _ to gettext themselves, net result being i18n'ed code running slower. It's not like we're going to add more single-character aliases, so I don't buy the feature creep argument either. L_A! (leave _ alone!) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
Re: [PHP-DEV] Woah
* On 2001-09-08 at 08:34, Zeev Suraski [EMAIL PROTECTED] excited the electrons to say: Not really. You only have to conform if you believe that PHP is not a standalone language. You're also assuming that most of PHP's userbase has C background, which is usually not true. Among those coming from C background, usually they have a limited one, and would not be used to gettext() aliases. This sort of argument keeps coming up, but Zeev is the lucky one who sets me off.. :-) People are very free to speak about what *others* expect. Unless you are one of them, or have concrete evidence, then such remarks are nothing more than speculation, and the electrons that conveyed them are already doing other things. :-) For instance: Zeev, did you come to PHP from C? Did/do you use gettext in other languages? If the answer to the latter, at least, is 'no' then I think the experience of people like Rasmus and Chuck -- who *do* use gettext a lot, and in other languages -- carries a helluva lot more weight than your speculation and that of other non-gettext-users. Inconveniencing your long-time users in the name of language purity is, IMHO, just plain stupid. I'm not sure why you're failing to see the fundamental difference between a function that is complex and perhaps requires prior knowledge, and an entry that obscures the *namespace* of PHP. And I personally am not sure why the 'get rid of _' faction is failing to see that doing so would be a language REGRESSION, not a step forward. Please tell me of some examples in other languages in which long-time warts with thousands of users have been removed in later versions in the name of 'language purity.' If you can name some, cool; I will be less ignorant, and might reconsider my position. Otherwise, d'you think PHP should be *that* kind of groundbreaker? :-) Look, I think there is no question that removing '_()' is going to BREAK some users. I do not see how anyone can consider that a Good Thing. I suggest that it be left in, and documented more clearly, and the documentation updated to say 'the use of gettext() is highly recommended and preferred over that of _()'. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Rasmus Lerdorf wrote: Using obscure single character operators is simply something that we don't do in PHP, it's totally inconsistent with the language. You know I hate magic more than most. I have lobbied against it forever. However, sometimes you need to conform with the underlying 3rd-party mechanism you are connecting to. If only for migration purposes. If someone knows the technology, then we don't want to force another interface to it, and if they don't, then providing a different interface to it to insulate them from the real magic does them, IMO, a disservice. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither -- 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]
Re: [PHP-DEV] Woah
At 16:37 08-09-01, Jim Jagielski wrote: Rasmus Lerdorf wrote: Using obscure single character operators is simply something that we don't do in PHP, it's totally inconsistent with the language. You know I hate magic more than most. I have lobbied against it forever. However, sometimes you need to conform with the underlying 3rd-party mechanism you are connecting to. If only for migration purposes. If someone knows the technology, then we don't want to force another interface to it, and if they don't, then providing a different interface to it to insulate them from the real magic does them, IMO, a disservice. By that logic, PHP should be the supermarket of all other languages. Theory aside, if we look into the actual issue at hand: - I think it's a fair and safe assumption to make that there are a lot more PHP users who are not familiar with gettext at all than those who are. - I think it's a fair and safe assumption to make that out of those who do use gettext, a large number had no prior knowledge of other languages, and/or of gettext in other languages. - Out of the small remaining number of people who do use gettext *and* are used to working with it in other languages *and* used _() in that other language, none of them will be disappointed to find _() missing, because if they really miss it, they can create it in a second. Just like they do in C, by the way. On the other hand, when the rest of the PHP users come across scripts using _(), they're completely stumped. It doesn't look like a function, it's undocumented. Weighting the pros and cons is an easy call in my opinion. The *only* issue I see here is downwards compatibility (which can be solved, as it has been solved numerous times in the past, and especially as this function was never directly documented). Zeev -- 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]
Re: [PHP-DEV] Woah
Just to add my few £0.02 to this discussion :)
_() just doesnt make sense to anyone who hasnt used gettext() which tbh is
probably the vast majority of the comunity, I have seen _ in the function
lists and Zend and Harmuts site and just thought it was a querk somewhere..
_() to me looks like some sort of Perlish operator, the fact that gettext in
C allows you to use it doesnt make it right for PHP, the gettext obviously
have a different naming system to PHP.
I would say that it clutters the namespace and is ugly and there is no
reason for it to be there, if you are worried about performance then try
running this on your file after you have coded it:
sed -e's%_(%gettext(%g' file.php temp' cp temp $file
OK its a pain in the arse to do every time but tbh I think that echo is used
a lot more so lets make echo aliased as ^(.) oh and perhaps we should
have sprintf as *() and dont forget while.. I bet perople get bored of
typing that so lets make it (conditional expreesion) { }
and perhsps we then need some for switch and if I think ? and would be
good candidates for them, right now as mysql is the main database used with
PHP lets save people some typing but loosing the mysql_ infront of it and
have connect, query, fetch_array.. but that might be unfair on the pgsql
users so lets add a special operator as the first line of the script which
can choose between pg or mysql maybe somthing like %m or %p.. then we could
have a great looking script like the following:
?php
%m;
$dc = connect(blah,blah);
select_db(blah,$dc);
$sql = SELECT * FROM ._(lang table);
$r = query($sql);
($row = fetch_array($r))
{
($row[0])
{
^($row[0]);
}
}
?
I personally think that looks quite good.. Ive even managed to save myself
typing a whole 27 characters.. now I can type at 30 odd words a min..
average length 5 letters.. thats a whole 5.4 seconds do you really think
loosing readability is that worth it, most people can type fast enough so
that gettext makes very little timewise to _(, its more readable and
promotes good code rather than lazyness.
- James
--
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]
Re: [PHP-DEV] Woah
On Sat, 08 Sep 2001, Zeev Suraski wrote:
Again, by deprecating it now, the immediate action would be removing any
reference to it from the documentation (the very little there is). There
are a hell of a lot PHP users to come than there are existing users of PHP,
so we might as well limit the scope of the problem. We can also advertise
that this function will not be staying with us in the future, and that
people should use gettext() instead. We can add an E_NOTICE to it, which
would make fixing it a trivial single command. When we actually remove this
alias can be determined in the future.
To me personally, gettext('This is my string') is a lot uglier than
_('This is my String'). I think _() could be made an exception to the
function-naming rule.
-Andrei
Give a man a fish; you have fed him for today. Teach a man to fish;
and you can sell him fishing equipment.
-Author unknown
--
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]
Re: [PHP-DEV] Woah
On Fri, 07 Sep 2001, Cristopher Daniluk wrote:
Again, as mentioned before, this is suitable:
function _($string) { return gettext($string); }
once in your code. Voila, now you can still have your short cut, and we can
still have our consistent naming structure. Sure, it would be an adjustment
at first, but I personally believe it is worth it. We don't lose anything
other than maybe 5 minutes of confusion after upgrading. By making it VERY
clear in the release update, we can avoid major headache. For what it's
worth:
Having a user-space alias such as this will make the i18n'ed programs
run slower.
-Andrei
Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.
--
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]
RE: [PHP-DEV] Woah
I think the argument is more consistency in the language than anything. Sure we'd be regressing symantically, but we've done it before for the better of the language. I proposed the user just creating a userspace function. Granted not perfect. Rasmus came up with, in my opinion, the much better idea of defining a function alias at runtime. The unfortunate defect of course is that PHP doesn't support that, but maybe this is a good reason why it should. Having runtime aliases gives us a clear and dependable way to deal with this problem now, AND in the future. I can attest to some of the mind bogglingly stupid function naming that pops up here and there in PHP, and this gives a consistent way to deal with it - users should fix it, but are more than welcome to just have an alias. We could even let aliases be defined in php.ini so they're global. We clearly have our roots in dozens of languages, but that does not mean we need to be confined to those roots in a policy of strict appeasement. I think, among other things, PHP has earned the right to break away from this appeasement game and set our own standards and our own rules. When we stop living in the shadows of other languages is when we will move from a good language to a great one. Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 08, 2001 9:29 AM To: PHP developer list Subject: Re: [PHP-DEV] Woah * On 2001-09-08 at 08:34, Zeev Suraski [EMAIL PROTECTED] excited the electrons to say: Not really. You only have to conform if you believe that PHP is not a standalone language. You're also assuming that most of PHP's userbase has C background, which is usually not true. Among those coming from C background, usually they have a limited one, and would not be used to gettext() aliases. This sort of argument keeps coming up, but Zeev is the lucky one who sets me off.. :-) People are very free to speak about what *others* expect. Unless you are one of them, or have concrete evidence, then such remarks are nothing more than speculation, and the electrons that conveyed them are already doing other things. :-) For instance: Zeev, did you come to PHP from C? Did/do you use gettext in other languages? If the answer to the latter, at least, is 'no' then I think the experience of people like Rasmus and Chuck -- who *do* use gettext a lot, and in other languages -- carries a helluva lot more weight than your speculation and that of other non-gettext-users. Inconveniencing your long-time users in the name of language purity is, IMHO, just plain stupid. I'm not sure why you're failing to see the fundamental difference between a function that is complex and perhaps requires prior knowledge, and an entry that obscures the *namespace* of PHP. And I personally am not sure why the 'get rid of _' faction is failing to see that doing so would be a language REGRESSION, not a step forward. Please tell me of some examples in other languages in which long-time warts with thousands of users have been removed in later versions in the name of 'language purity.' If you can name some, cool; I will be less ignorant, and might reconsider my position. Otherwise, d'you think PHP should be *that* kind of groundbreaker? :-) Look, I think there is no question that removing '_()' is going to BREAK some users. I do not see how anyone can consider that a Good Thing. I suggest that it be left in, and documented more clearly, and the documentation updated to say 'the use of gettext() is highly recommended and preferred over that of _()'. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: [PHP-DEV] Woah
Agreed, but is the speed loss really worth crying about? It is negligible
calling a userspace function versus an internal compared to the greater work
that the typical PHP script does. Hell, it's negligible compared to the work
gettext does! Nevertheless, your point is made and is fair at that. I
propose tackling the problem as mentioned in my previous email, by devising
a new runtime function aliasing system ala C #DEFINE style. This can satisfy
all parties involved, and while it won't be the easiest solution, I think it
will be the most beneficial in future problems of similar nature.
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 08, 2001 11:48 AM
To: Cristopher Daniluk
Cc: 'Chuck Hagenbuch'; 'Joey Smith'; 'PHP Developer List'
Subject: Re: [PHP-DEV] Woah
On Fri, 07 Sep 2001, Cristopher Daniluk wrote:
Again, as mentioned before, this is suitable:
function _($string) { return gettext($string); }
once in your code. Voila, now you can still have your short cut, and we
can
still have our consistent naming structure. Sure, it would be an
adjustment
at first, but I personally believe it is worth it. We don't lose anything
other than maybe 5 minutes of confusion after upgrading. By making it VERY
clear in the release update, we can avoid major headache. For what it's
worth:
Having a user-space alias such as this will make the i18n'ed programs
run slower.
-Andrei
Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.
BEGIN:VCARD
VERSION:2.1
N:Daniluk;Cristopher
FN:Cristopher Daniluk
ORG:Digital Services Network, Inc.;Executive Management
TITLE:President CEO
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A
TEL;WORK;VOICE:(330) 530-2373
TEL;WORK;VOICE:(800) 845-4822
TEL;CELL;VOICE:(330) 219-4819
TEL;WORK;FAX:(208) 723-6782
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S=
tates of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443=
7=0D=0AUnited States of America
URL;WORK:http://www.dsnet.net/~cris
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010528T230445Z
END:VCARD
--
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]
Re: [PHP-DEV] Woah
At 09:36 08-09-01, Rasmus Lerdorf wrote:
Using obscure single character operators is simply something that we don't
do in PHP, it's totally inconsistent with the language.
You know I hate magic more than most. I have lobbied against it forever.
Well, you did in certain occasions, but you encouraged certain degrees of
magic in the past.
As did you. You don't call ?= magic? You lobbied hard to make that
active by default. I wouldn't call ?=Whoa? pure, would you? If you
don't know what it does, where do you start looking?
?= is obviously a concession to ASP users who are used to using %= just
like _() is a concession to gettext users. I don't quite see how you can
argue strongly in favour of ?= and at the same time argue so strongly
against _(). Magic is bad and language consistency is good, but allowing
users who are used to certain conventions to continue using them is
sometimes a tradeoff that is worth making.
Regular expression are butt-ugly by definition. You can either learn them
or not learn them. It's kinda like SQL. I'm not sure why you're failing
to see the fundamental difference between a function that is complex and
perhaps requires prior knowledge, and an entry that obscures the
*namespace* of PHP.
There is a heck of a lot more to gettext than just knowing the gettext()
function. Anybody who inherits code which uses gettext is going to have
to read up on textdomain, .po files and the other related crud and
understand the conventions. One of these conventions, like it or not, is
_(). None of this stuff is covered in the PHP documentation. Just like
anybody who inherits PHP code with regular expressions or complex SQL are
going to have to read up on the conventions of those technologies which
also aren't covered in the PHP docs.
When I see ereg_replace(), I can go and learn about regular expressions.
When I see _(), I don't have the faintest clue what the heck it is. If I
even figure out that this is a function (it sure as hell doesn't look like
one):
(a) Consult the manual (won't do)
(b) Consult the function table (won't do)
If I don't, I can either read the source code or start up a debugger.
Exactly the same goes for ?= unless you happen to stumble across the
one-line footnote on the php.net/echo page.
Cris showed a trivial way of doing that, if users actually want to do
it. function _($str) { return gettext($str); }. You don't need any new
mechanisms or magic to do this.
We both know that this is going to affect performance. Just for kicks I
tested this on one of my gettext pages. I picked a relatively simple one
that didn't have any SQL or LDAP queries in it. With the _() calls it
managed 110 requests/second. With:
function g($str) { return gettext($str); }
it got 81 requests/second. To me that is not a trivial workaround. And
like I mentioned before, if we had some way of installing this function in
the namespace dynamically, I would be all for it.
At least give the user the option to decide whether he wants to pollute his
namespace. At least give the code readers a chance to figure out what's
going on by grepping the PHP source code. Sending them to the C source
code or to debuggers is the old style thinking of PHP. Most new comers to
PHP today have no C knowledge.
And most have ASP knowledge? And where is my option to not pollute PHP
with ?= ? Even with asp_tags set to off ?= is still active.
-Rasmus
--
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]
Re: [PHP-DEV] Woah
Rasmus Lerdorf wrote: ?= is obviously a concession to ASP users who are used to using %= just like _() is a concession to gettext users. And ?= is in the 'core', while _() is only available when gettext is loaded. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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]
Fwd: Re: [PHP-DEV] Woah
Ken - see my point? :)
Andrei - ugliness is not a metrics, anymore than disappointment is. Fact -
gettext(foo) is much less magical and much more understandable than _(foo).
Date: Sat, 8 Sep 2001 10:45:53 -0500
From: Andrei Zmievski [EMAIL PROTECTED]
To: Zeev Suraski [EMAIL PROTECTED]
Cc: Chuck Hagenbuch [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Woah
On Sat, 08 Sep 2001, Zeev Suraski wrote:
Again, by deprecating it now, the immediate action would be removing any
reference to it from the documentation (the very little there is). There
are a hell of a lot PHP users to come than there are existing users of
PHP,
so we might as well limit the scope of the problem. We can also advertise
that this function will not be staying with us in the future, and that
people should use gettext() instead. We can add an E_NOTICE to it, which
would make fixing it a trivial single command. When we actually remove
this
alias can be determined in the future.
To me personally, gettext('This is my string') is a lot uglier than
_('This is my String'). I think _() could be made an exception to the
function-naming rule.
-Andrei
Give a man a fish; you have fed him for today. Teach a man to fish;
and you can sell him fishing equipment.
-Author unknown
--
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]
Re: [PHP-DEV] Woah
At 19:29 08-09-01, Rasmus Lerdorf wrote:
At 09:36 08-09-01, Rasmus Lerdorf wrote:
Using obscure single character operators is simply something that
we don't
do in PHP, it's totally inconsistent with the language.
You know I hate magic more than most. I have lobbied against it forever.
Well, you did in certain occasions, but you encouraged certain degrees of
magic in the past.
As did you. You don't call ?= magic? You lobbied hard to make that
active by default. I wouldn't call ?=Whoa? pure, would you? If you
don't know what it does, where do you start looking?
I don't consider ?= magic anymore than ?. It should be documented in the
list of PHP's special tags. You could argue the same about ? itself,
they're equally fundamental. _() is magic, magic quotes is magic. ?= is
some trick, at best :)
There is a heck of a lot more to gettext than just knowing the gettext()
function. Anybody who inherits code which uses gettext is going to have
to read up on textdomain, .po files and the other related crud and
understand the conventions. One of these conventions, like it or not, is
_(). None of this stuff is covered in the PHP documentation. Just like
anybody who inherits PHP code with regular expressions or complex SQL are
going to have to read up on the conventions of those technologies which
also aren't covered in the PHP docs.
You still don't see the point. People don't have the faintest clue that
_() is even related to gettext! It doesn't look like a function but as
some form of an internal operator.
Exactly the same goes for ?= unless you happen to stumble across the
one-line footnote on the php.net/echo page.
So that's a documentation bug. It clearly belongs in the documentation
about PHP's various special tags, just next to ?php, ?, %, %= script
language=php, etc. There's a logical place to look for that entry.
Cris showed a trivial way of doing that, if users actually want to do
it. function _($str) { return gettext($str); }. You don't need any new
mechanisms or magic to do this.
We both know that this is going to affect performance. Just for kicks I
tested this on one of my gettext pages. I picked a relatively simple one
that didn't have any SQL or LDAP queries in it. With the _() calls it
managed 110 requests/second. With:
function g($str) { return gettext($str); }
it got 81 requests/second. To me that is not a trivial workaround. And
like I mentioned before, if we had some way of installing this function in
the namespace dynamically, I would be all for it.
We could have a way of aliasing functions.
At least give the user the option to decide whether he wants to pollute his
namespace. At least give the code readers a chance to figure out what's
going on by grepping the PHP source code. Sending them to the C source
code or to debuggers is the old style thinking of PHP. Most new comers to
PHP today have no C knowledge.
And most have ASP knowledge? And where is my option to not pollute PHP
with ?= ? Even with asp_tags set to off ?= is still active.
You're right that ?= is not self explanatory. FWIW, it still falls in a
very clear category of language-level features, right next to ? and ?php,
which you have to learn anyway (and again, if it's missing, so that's a
documentation bug that can be fixed). This is not something you could say
about _().
Zeev
--
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]
Re: [PHP-DEV] Woah
At 01:24 09-09-01, Jeroen van Wolffelaar wrote: Exactly the same goes for ?= unless you happen to stumble across the one-line footnote on the php.net/echo page. So that's a documentation bug. It clearly belongs in the documentation about PHP's various special tags, just next to ?php, ?, %, %= script language=php, etc. There's a logical place to look for that entry. FYI, 'I' added ?= on May 10th to the documentation along with the rest of ?php etc, because I noticed it wasn't there... Cool. Hm, what I wrote was somewhat ambigious, I meant to say that I added ?= on the place where the other variants were already present. So I added JUST ?=, NOT the others. I don't know wether you understood me wrong, but just to be sure... --Jeroen -- 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]
Re: Fwd: Re: [PHP-DEV] Woah
On Sun, Sep 09, 2001 at 12:46:17AM +0300, Zeev Suraski wrote: Fact - gettext(foo) is much less magical and much more understandable than _(foo). I think the problem here is that internationalization is being considered a 'separate module', rather than a core piece of functionality that PHP should account for. Right now, wrapping _() around EVERY string is only the first step. Then you have to figure out how .po files, bindtextdomain, various environment variables, and all the other stuff that gettext imposes on the system actually work. So where have the PHP ideals disappeared to in simplying this? This whole _() argument is merely a symptom of the underlying problem that internationalizing PHP scripts is really actually quite difficult and intrusive. Fix that, and this particular problem goes away. If you really believe that deprecating _() is a good thing in the context of using gettext, I find it hard to believe that you've actually implemented i8n in PHP for a large project. Personally, I've only used it when Horde switched to it, and I think I'd go mad if I had to wrap every string in the full version of gettext() ! The GNU manual expresses this pretty well: the textual overhead per translatable string is reduced to only three characters: the underline and the two parentheses When we're talking about every single string in your project, that's pretty significant. Anil -- 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]
RE: [PHP-DEV] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]: Agreed, but is the speed loss really worth crying about? Obviously not to you, but I'm pretty sure you came down in the category of people who'd never used gettext. It is negligible calling a userspace function versus an internal compared to the greater work that the typical PHP script does. What authority do you have to make this statement? Rasmus posted numbers. Where are yours? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
RE: [PHP-DEV] Woah
I feel like you're getting a bit personal here, but I'll refrain from doing
the same and simply provide numbers. This is a demonstration to prove purely
the overhead of going into a userspace function that calls an internal
versus calling the internal directly. Obviously this isn't scientific, but
that's not my goal.
3 scripts were created. First called _(). Second defined a function as
follows:
function b($str) { return gettext($str); }
Third b() instead of _() - note the second one was created just to try
and normalize out any deviance from parsing the new function.
Apache Bench was run at 1000 queries to give enough performance to
illustrate a significant deviance. A concurrency of 10 and 100 were used.
Each set was run 3 times and averages were taken to normalize outside
factors. Tests were run randomly at various times throughout the last hour,
to reduce the effect of foreign elements.
First Test (using _)
Concurrency 10: 50.24/50.23/57.43 = 52.63
Concurrency 100: 44.58/46.59/44.53 = 46.23
Second Test (defining b)
Concurrency 10: 55.05/56.19/50.55 = 53.93
Concurrency 100: 45.65/47.06/45.71 = 46.12
Third Test (using b)
Concurrency 10: 55.16/55.82/52.16 = 54.38
Concurrency 100: 46.74/46.39/47.19 = 46.77
I really truly and with all my heart believe that if simply calling a user
created function could drop performance by 25%, PHP would not be a viable
language. Whether my results are accurate findings or not, Rasmus's
demonstration of a 26.3% performance decrease by CALLING A FUNCTION is a lot
to swallow!
Oh, and I'll refrain from making the muse that the latter test was faster.
Having the user make their own function may not be the right solution for
this problem, but its phenomenally silly to argue that it would have a large
performance impact!
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: Chuck Hagenbuch [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 08, 2001 7:23 PM
To: [EMAIL PROTECTED]
Cc: 'PHP Developer List'
Subject: RE: [PHP-DEV] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]:
Agreed, but is the speed loss really worth crying about?
Obviously not to you, but I'm pretty sure you came down in the category of
people who'd never used gettext.
It is negligible calling a userspace function versus an internal compared
to
the greater work that the typical PHP script does.
What authority do you have to make this statement? Rasmus posted numbers.
Where
are yours?
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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]
BEGIN:VCARD
VERSION:2.1
N:Daniluk;Cristopher
FN:Cristopher Daniluk
ORG:Digital Services Network, Inc.;Executive Management
TITLE:President CEO
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A
TEL;WORK;VOICE:(330) 530-2373
TEL;WORK;VOICE:(800) 845-4822
TEL;CELL;VOICE:(330) 219-4819
TEL;WORK;FAX:(208) 723-6782
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S=
tates of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443=
7=0D=0AUnited States of America
URL;WORK:http://www.dsnet.net/~cris
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010528T230445Z
END:VCARD
--
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]
Re: [PHP-DEV] Woah
Quoting Rasmus Lerdorf [EMAIL PROTECTED]: This doesn't mean I agree with the magic _() function, but until we have some sort of efficient run-time function aliasing mechanism like they do in Python, removing _() and telling people to create a user-space function that calls gettext() is not going to make the gettext using people very happy with us. The way this was solved in Python is that they have a gettext.install method which creates the _() function in the builtin namespace. The function is only present once this install method is called on the gettext object. See http://www.python.org/doc/2.1/lib/node187.html Having some elegant solution like either of the ones outlined above would go a long way towards making yanking _() out of the gettext module seem reasonable to me. Zeev: were it being added now, no, I wouldn't argue for it. My argument is based on it having been there for years and being in heavy use in some people's code. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Benchmarking the execution time for a single function call by making a
page and request it via b is a pretty flawed method. While it may show
that a single aliased call to gettext() doesn't change the execution
time of a script by much, it does not say anything about the relative
times for execution of a specific function. You should call the
function in a type loop and average over many executions. Here's a
sample you can try:
strlen.php:
?
$a = 'blah';
while($i 10) {
$b = strlen($a);
$i++;
}
?
gstrlen.php:
?
$a = 'blah';
while($i 10) {
$b = gstrlen($a);
$i++;
}
function gstrlen($str) {
return strlen($str);
}
?
22:54:00(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/strlen.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
0.840u 0.010s 0:00.85 100.0%0+0k 0+0io 293pf+0w
22:54:17(george@wasabi)[~/src/php-4.0.6/ext] time php
/opt/apache/htdocs/gstrlen.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
1.950u 0.010s 0:01.95 100.5%0+0k 0+0io 295pf+0w
When done often enough, the difference between calling userland
functions and builtins is _huge_. Substitute your favorite function in
for strlen (I tried a bunch), you'll get similair results. Having to
switch executor contexts evertime you call a userland function is really
expensive.
George
On Saturday, September 8, 2001, at 08:07 PM, Cristopher Daniluk wrote:
I feel like you're getting a bit personal here, but I'll refrain from
doing
the same and simply provide numbers. This is a demonstration to prove
purely
the overhead of going into a userspace function that calls an internal
versus calling the internal directly. Obviously this isn't scientific,
but
that's not my goal.
3 scripts were created. First called _(). Second defined a function as
follows:
function b($str) { return gettext($str); }
Third b() instead of _() - note the second one was created just to
try
and normalize out any deviance from parsing the new function.
Apache Bench was run at 1000 queries to give enough performance to
illustrate a significant deviance. A concurrency of 10 and 100 were
used.
Each set was run 3 times and averages were taken to normalize outside
factors. Tests were run randomly at various times throughout the last
hour,
to reduce the effect of foreign elements.
First Test (using _)
Concurrency 10: 50.24/50.23/57.43 = 52.63
Concurrency 100: 44.58/46.59/44.53 = 46.23
Second Test (defining b)
Concurrency 10: 55.05/56.19/50.55 = 53.93
Concurrency 100: 45.65/47.06/45.71 = 46.12
Third Test (using b)
Concurrency 10: 55.16/55.82/52.16 = 54.38
Concurrency 100: 46.74/46.39/47.19 = 46.77
I really truly and with all my heart believe that if simply calling a
user
created function could drop performance by 25%, PHP would not be a
viable
language. Whether my results are accurate findings or not, Rasmus's
demonstration of a 26.3% performance decrease by CALLING A FUNCTION is
a lot
to swallow!
Oh, and I'll refrain from making the muse that the latter test was
faster.
Having the user make their own function may not be the right solution
for
this problem, but its phenomenally silly to argue that it would have a
large
performance impact!
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: Chuck Hagenbuch [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 08, 2001 7:23 PM
To: [EMAIL PROTECTED]
Cc: 'PHP Developer List'
Subject: RE: [PHP-DEV] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]:
Agreed, but is the speed loss really worth crying about?
Obviously not to you, but I'm pretty sure you came down in the category
of
people who'd never used gettext.
It is negligible calling a userspace function versus an internal
compared
to
the greater work that the typical PHP script does.
What authority do you have to make this statement? Rasmus posted
numbers.
Where
are yours?
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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]
BEGIN:VCARD
VERSION:2.1
N:Daniluk;Cristopher
FN:Cristopher Daniluk
ORG:Digital Services Network, Inc.;Executive Management
TITLE:President CEO
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A
TEL;WORK;VOICE:(330) 530-2373
TEL;WORK;VOICE:(800) 845-4822
TEL;CELL;VOICE:(330) 219-4819
TEL;WORK;FAX:(208) 723-6782
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S=
tates
Re: [PHP-DEV] Woah
These are two of the most ridiculous statements I have *EVER* heard anyone make. Cleaning up a language is a benefit worth paying in price for. How many millions of lines of C code had to be re-written when the ANSI standard was published? And I'm not personally sure, but I'd be willing to bet that the same thing happened once C++ was standardized. There's 2 *VERY* big examples. But even if these examples *WEREN'T* there, it makes me question your intelligence to read this email. Let me try and rephrase, so you can see how this sounds: Look, if no one else out there has had the balls or the brains to forbid this kind of behavior, it doesn't matter whether it's wrong or not, we should be good little sheep and follow along. This is either the stupidest, or the most cowardly email I have read on php-dev to dateI just can't decide which. Inconveniencing your long-time users in the name of language purity is, IMHO, just plain stupid. SNIP And I personally am not sure why the 'get rid of _' faction is failing to see that doing so would be a language REGRESSION, not a step forward. Please tell me of some examples in other languages in which long-time warts with thousands of users have been removed in later versions in the name of 'language purity.' If you can name some, cool; I will be less ignorant, and might reconsider my position. Otherwise, d'you think PHP should be *that* kind of groundbreaker? :-) Look, I think there is no question that removing '_()' is going to BREAK some users. I do not see how anyone can consider that a Good Thing. I suggest that it be left in, and documented more clearly, and the documentation updated to say 'the use of gettext() is highly recommended and preferred over that of _()'. -- 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]
Re: [PHP-DEV] Woah
Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c That has been there forever and is very standard. Anybody who has ever used gettext knows this well. From the gettext docs: Many packages use `_' (a simple underline) as a keyword, and write `_(Translatable string)' instead of `gettext (Translatable string)'. Further, the coding rule, from GNU standards, wanting that there is a space between the keyword and the opening parenthesis is relaxed, in practice, for this particular usage. So, the textual overhead per translatable string is reduced to only three characters: the underline and the two parentheses. However, even if GNU gettext uses this convention internally, it does not offer it officially. The real, genuine keyword is truly `gettext' indeed. It is fairly easy for those wanting to use `_' instead of `gettext' to declare: #include libintl.h #define _(String) gettext (String) -Rasmus -- 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]
Re: [PHP-DEV] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c It's a standard alias in the c library as well: http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC15 It makes code look a lot less convoluted, when you just wrap strings in _() instead of having gettext() all over the place. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
At 05:16 08-09-01, Chuck Hagenbuch wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c It's a standard alias in the c library as well: http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC15 So I heard, but it's extremely un-PHPish and obscure. Zeev -- 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]
Re: [PHP-DEV] Woah
At 05:13 08-09-01, Rasmus Lerdorf wrote: Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c That has been there forever and is very standard. Anybody who has ever used gettext knows this well. The problem is with the 99.99% of the rest of the world, who doesn't know about it. I know it's been there since gettext was introduced, and that's a pity. Zeev -- 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]
RE: [PHP-DEV] Woah
But it IS PHP-ish in the sense that its totally undocumented :) Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 10:22 PM To: Chuck Hagenbuch Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Woah At 05:16 08-09-01, Chuck Hagenbuch wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: Why the heck do we have: PHP_FALIAS(_, gettext,NULL) in ext/gettext/gettext.c It's a standard alias in the c library as well: http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC15 So I heard, but it's extremely un-PHPish and obscure. Zeev -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
Re: [PHP-DEV] Woah
At 05:16 08-09-01, Chuck Hagenbuch wrote:
Quoting Zeev Suraski [EMAIL PROTECTED]:
Why the heck do we have:
PHP_FALIAS(_, gettext,NULL)
in ext/gettext/gettext.c
It's a standard alias in the c library as well:
http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC15
So I heard, but it's extremely un-PHPish and obscure.
Having an underscore as a function name is pretty weird in any language.
But it is also extremely useful. I have reams and reams of PHP code that
has _('blah blah blal') in it. When you internationalize a large site,
typing gettext() thousands of times does get rather old very quickly.
-Rasmus
--
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]
Re: [PHP-DEV] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: So I heard, but it's extremely un-PHPish and obscure. It also makes gettext useable. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
At 05:23 08-09-01, Rasmus Lerdorf wrote:
Having an underscore as a function name is pretty weird in any language.
Having an obscure meaning to characters is common in certain languages, but
PHP isn't one of them. C isn't either, and frankly, I don't think that
going with _() was a very good choice in there either.
But it is also extremely useful. I have reams and reams of PHP code that
has _('blah blah blal') in it. When you internationalize a large site,
typing gettext() thousands of times does get rather old very quickly.
That's fine and dandy, except gettext() is just one way to internationalize
a site, and there are all sorts of other functionalities people use and
reuse. We can get back to the idea of letting people define % as
htmlspecialchars(), because that's very often used. Why not use $_C
instead of $_COOKIE, in the new variables code? That'd save just as many
keystrokes, and people use cookies all the time.
Using obscure single character operators is simply something that we don't
do in PHP, it's totally inconsistent with the language.
Zeev
--
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]
Re: [PHP-DEV] Woah
At 05:30 08-09-01, Chuck Hagenbuch wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: So I heard, but it's extremely un-PHPish and obscure. It also makes gettext useable. I don't buy that. 'gettext' is hardly the only token that's used repeatedly throughout PHP, and we never made any exceptions anywhere else. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php That's unfortunate. IMHO, it should be phased out. Zeev -- 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]
Re: [PHP-DEV] Woah
At 05:30 08-09-01, Chuck Hagenbuch wrote: It also makes gettext useable. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php There's no mention of _() in that page, by the way. Only gettext(). Zeev -- 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]
Re: [PHP-DEV] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: It also makes gettext useable. I don't buy that. 'gettext' is hardly the only token that's used repeatedly throughout PHP, and we never made any exceptions anywhere else. It's the kind of thing that gets used a lot in HTML, where otherwise there wouldn't be a function call at _all_ - just static text. Replacing gettext() with _() in this case actually does improve readability, in my opinion. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php That's unfortunate. IMHO, it should be phased out. Exceptions in php extensions have been made before where the extension mirrors the c library exactly, in order to not confuse people familiar with the library. This is another one of those cases - people familiar with gettext will be very confused if _() doesn't work the way they expect it to. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Quoting Zeev Suraski [EMAIL PROTECTED]: There's no mention of _() in that page, by the way. Only gettext(). You may use an underscore character as an alias to this function. It could be clearer, certainly. But it's there. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Using obscure single character operators is simply something that we don't do in PHP, it's totally inconsistent with the language. Except when it is a known and standard concept. + % * etc. Obviously not as well-known, but it is not a PHP-only magical character. It is the same in C, C++, Perl, Python and Tcl. -Rasmus -- 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]
RE: [PHP-DEV] Woah
Same in Perl? I have not used Gettext in Perl, but I'd truly hope not considering the overwhelming usage of $_. Can you imagine _ and $_? That's not what I'd call increased readability. Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 10:38 PM To: Zeev Suraski Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Woah Using obscure single character operators is simply something that we don't do in PHP, it's totally inconsistent with the language. Except when it is a known and standard concept. + % * etc. Obviously not as well-known, but it is not a PHP-only magical character. It is the same in C, C++, Perl, Python and Tcl. -Rasmus -- 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] BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
Re: [PHP-DEV] Woah
At 05:40 08-09-01, Chuck Hagenbuch wrote: It's the kind of thing that gets used a lot in HTML, where otherwise there wouldn't be a function call at _all_ - just static text. Replacing gettext() with _() in this case actually does improve readability, in my opinion. That's exactly what I said - there are several other functions/operators/labels which are used a lot and repeatedly, and we never made any exceptions as far as clarity goes. It's documented, for what it's worth: http://www.php.net/manual/en/function.gettext.php That's unfortunate. IMHO, it should be phased out. Exceptions in php extensions have been made before where the extension mirrors the c library exactly, in order to not confuse people familiar with the library. This is another one of those cases - people familiar with gettext will be very confused if _() doesn't work the way they expect it to. You're talking about exceptions in the naming convention? Well, the more accurate way to describe it is that originally, modules tried to copy the low-level API function names 1::1. Only at a later stage we started to strive towards a standard naming convention. Today, when adding new functionality, the low level API function names play no role, and the functions are named using the PHP naming convention. We explicitly decided that in the lengthy discussion about function naming convention that took place half a year ago or so. There was no clear decision as to what to do with the existing functions that are named after their low-level counterparts. At any rate, this is not the kind of exception I was talking about. _ includes 0.0 information about what it does, and unless you know exactly what it does, you're lost. It's not an issue of shortening words, or neglecting to put underscores between words. Not only do you not stand a chance understanding what you're reading without looking at documentation, but you also have absolutely no way of finding what this does if you actually look it up in a manual. Zeev Zeev -- 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]
Re: [PHP-DEV] Woah
* On 2001-09-07 at 23:06, Joey Smith [EMAIL PROTECTED] excited the electrons to say: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. Um, it has been around since sometime in version 3. Have you noticed it before? Has it bothered you? I think at this point it should be considered a legacy exception. Getting rid of it is going to break a lot of existing *user* scripts. Doing that to them for the sake of language elegance hardly sounds like a good idea to me.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Quoting Joey Smith [EMAIL PROTECTED]: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. I know that backwards compatibility is a pain in the ass, but you might want to consider that this has been around ever since the gettext extension was introduced, before launching the next crusade. Just out of the curiosity, have any of the people jumping on the bandwagon to bash this ever actually _used_ gettext at any kind of scale? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
Yes, it bothers me. If it stays, I suppose I'll accept it, but it is such a horrendously bad idea that could easily be done in user-space insteadthis is *NOT* the kind of thing that should be encouraged on a language level. On Fri, 7 Sep 2001, Rodent of Unusual Size wrote the following to PHP...: * On 2001-09-07 at 23:06, Joey Smith [EMAIL PROTECTED] excited the electrons to say: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. Um, it has been around since sometime in version 3. Have you noticed it before? Has it bothered you? I think at this point it should be considered a legacy exception. Getting rid of it is going to break a lot of existing *user* scripts. Doing that to them for the sake of language elegance hardly sounds like a good idea to me.. -- 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]
Re: [PHP-DEV] Woah
No, I haven't, but let me get this straight: You're saying that if something is a bad idea, that the more often it is used, the less bad [1] it becomes? [1] Yes, I know this is improper...but think about it in context. I'm trying to illustrate the point. On Fri, 7 Sep 2001, Chuck Hagenbuch wrote the following to Joey Smith : Quoting Joey Smith [EMAIL PROTECTED]: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. I know that backwards compatibility is a pain in the ass, but you might want to consider that this has been around ever since the gettext extension was introduced, before launching the next crusade. Just out of the curiosity, have any of the people jumping on the bandwagon to bash this ever actually _used_ gettext at any kind of scale? -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
Re: [PHP-DEV] Woah
* On 2001-09-07 at 23:40, Joey Smith [EMAIL PROTECTED] excited the electrons to say: On Fri, 7 Sep 2001, Rodent of Unusual Size wrote the following to PHP...: Um, it has been around since sometime in version 3. Have you noticed it before? Has it bothered you? Yes, it bothers me. But has it bothered you before this discussion, is what I meant. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
RE: [PHP-DEV] Woah
Again, as mentioned before, this is suitable:
function _($string) { return gettext($string); }
once in your code. Voila, now you can still have your short cut, and we can
still have our consistent naming structure. Sure, it would be an adjustment
at first, but I personally believe it is worth it. We don't lose anything
other than maybe 5 minutes of confusion after upgrading. By making it VERY
clear in the release update, we can avoid major headache. For what it's
worth:
Many packages use `_' (a simple underline) as a keyword, and write
`_(Translatable string)' instead of `gettext (Translatable string)'.
Further, the coding rule, from GNU standards, wanting that there is a space
between the keyword and the opening parenthesis is relaxed, in practice, for
this particular usage. So, the textual overhead per translatable string is
reduced to only three characters: the underline and the two parentheses.
However, even if GNU gettext uses this convention internally, it does not
offer it officially. The real, genuine keyword is truly `gettext' indeed. It
is fairly easy for those wanting to use `_' instead of `gettext' to declare:
#include libintl.h
#define _(String) gettext (String)
instead of merely using `#include libintl.h'.
-- end of paste
Even C's gettext doesn't build this in by default, it requires the DEVELOPER
to consciously make that decision.
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: Chuck Hagenbuch [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 07, 2001 11:30 PM
To: Joey Smith
Cc: PHP Developer List
Subject: Re: [PHP-DEV] Woah
Quoting Joey Smith [EMAIL PROTECTED]:
So let's be the first ones to get our heads on straight and get rid of
this ridiculous concept. It is, IMHO, one of the worst ideas in the
history of the world...I'd really rather be reading perl regular
expressions than this.
I know that backwards compatibility is a pain in the ass, but you might want
to
consider that this has been around ever since the gettext extension was
introduced, before launching the next crusade.
Just out of the curiosity, have any of the people jumping on the bandwagon
to
bash this ever actually _used_ gettext at any kind of scale?
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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]
BEGIN:VCARD
VERSION:2.1
N:Daniluk;Cristopher
FN:Cristopher Daniluk
ORG:Digital Services Network, Inc.;Executive Management
TITLE:President CEO
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A
TEL;WORK;VOICE:(330) 530-2373
TEL;WORK;VOICE:(800) 845-4822
TEL;CELL;VOICE:(330) 219-4819
TEL;WORK;FAX:(208) 723-6782
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S=
tates of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443=
7=0D=0AUnited States of America
URL;WORK:http://www.dsnet.net/~cris
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010528T230445Z
END:VCARD
--
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]
Re: [PHP-DEV] Woah
At 06:30 08-09-01, Chuck Hagenbuch wrote: Quoting Joey Smith [EMAIL PROTECTED]: So let's be the first ones to get our heads on straight and get rid of this ridiculous concept. It is, IMHO, one of the worst ideas in the history of the world...I'd really rather be reading perl regular expressions than this. I know that backwards compatibility is a pain in the ass, but you might want to consider that this has been around ever since the gettext extension was introduced, before launching the next crusade. We have more or less of a standard procedure to handle this sort of things in PHP. Step #1 is to remove it from the documentation completely. Step #2 is to create notices to encourage people to stop using it, and possibly an INI option to turn it off. Step #3 removes it altogether. Just out of the curiosity, have any of the people jumping on the bandwagon to bash this ever actually _used_ gettext at any kind of scale? I haven't, but then, I do use cookies all the time and don't find it a big requirement to write $_COOKIE. Seriously, it's not just an example. People would use $_GET, $_COOKIE, $_SERVER a hell of a lot more than gettext(). And still, we didn't try to come up with some nifty short for them. Note that gettext() isn't exactly get_an_international_version_of_this_string() either, it's just 7 letters for Perl's sake :) Zeev -- 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]
Re: [PHP-DEV] Woah
* On 2001-09-07 at 23:42, Joey Smith [EMAIL PROTECTED] excited the electrons to say: No, I haven't, but let me get this straight: You're saying that if something is a bad idea, that the more often it is used, the less bad [1] it becomes? Speaking only for myself and not Chuck, I would say, This is a decision that was made 2.5 years ago. It may have been the wrong decision then, but it is a waste of time second-guessing it now. Keeping similar things from happening is far more important than trying to revise history. That is what I would say. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger! -- 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]
Re: [PHP-DEV] Woah
Quoting Joey Smith [EMAIL PROTECTED]: No, I haven't, but let me get this straight: You're saying that if something is a bad idea, that the more often it is used, the less bad [1] it becomes? Uh, no. I was just pointing out that it's been around for a long time, and is used in a lot of code. Like Ken said, breaking it - many years later - for language elegance seems rather unproductive. If it were up for inclusion now, it'd be a completely different story. The _reason_ backwards compability is a pain in the ass is that sometimes you have to put up with things like this because they get entrenched. Also, I asked if the people bashing it had used gettext just because I'd imagine that people who had used a feature would have a better idea on whether or not it is obscure or useful. -chuck -- Charles Hagenbuch, [EMAIL PROTECTED] Some fallen angels have their good reasons. -- 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]
RE: [PHP-DEV] Woah
But I think the point is this function has no business in the core language.
Now we can satisfy that. It IS still obscure, but thats why I won't use it
:) Those who want to be obscure can choose to be on their own dime. We
should not encourage it though, we'll end up like VBScript, a language of
rules and their exceptions.
Regards,
Cristopher Daniluk
President CEO
email: [EMAIL PROTECTED]
direct: 330/530-2373
Digital Services Network, Inc
Unleashing Your Potential
voice: 800/845-4822
web: http://www.dsnet.net/
-Original Message-
From: Chuck Hagenbuch [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 07, 2001 11:56 PM
To: Joey Smith
Cc: PHP Developer List
Subject: Re: [PHP-DEV] Woah
Quoting Joey Smith [EMAIL PROTECTED]:
Did it occur to you that people who *DON'T* use gettext() frequently
have to maintain the code of those who do, and that _() isn't going to
make one lick of sense to them?
Given the suggestion to just have people who already use gettext to define
function _($string) { return gettext($string); }
.. this argument doesn't hold water, since it'll still be in the code, and
still be as obscure. Those people would have to _choose_ not to use _(), and
they can already make that choice now.
-chuck
--
Charles Hagenbuch, [EMAIL PROTECTED]
Some fallen angels have their good reasons.
--
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]
BEGIN:VCARD
VERSION:2.1
N:Daniluk;Cristopher
FN:Cristopher Daniluk
ORG:Digital Services Network, Inc.;Executive Management
TITLE:President CEO
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A
TEL;WORK;VOICE:(330) 530-2373
TEL;WORK;VOICE:(800) 845-4822
TEL;CELL;VOICE:(330) 219-4819
TEL;WORK;FAX:(208) 723-6782
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S=
tates of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443=
7=0D=0AUnited States of America
URL;WORK:http://www.dsnet.net/~cris
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010528T230445Z
END:VCARD
--
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]
Re: [PHP-DEV] Woah
Quoting Cristopher Daniluk [EMAIL PROTECTED]: But I think the point is this function has no business in the core language. It's not in the core language. It's in the gettext extension. -chuck -- I have pointy little boobs! - Jason -- 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]
RE: [PHP-DEV] Woah
Heh, touche on my poor terminology. What I mean is it has no business being a function brought to the table by PHP. Even if we moved it to PEAR in a GetText module I'd be a happier guy. What good are ignored standards? Regards, Cristopher Daniluk President CEO email: [EMAIL PROTECTED] direct: 330/530-2373 Digital Services Network, Inc Unleashing Your Potential voice: 800/845-4822 web: http://www.dsnet.net/ -Original Message- From: Chuck Hagenbuch [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 08, 2001 12:23 AM To: Cristopher Daniluk Cc: 'Joey Smith'; 'PHP Developer List' Subject: Re: [PHP-DEV] Woah Quoting Cristopher Daniluk [EMAIL PROTECTED]: But I think the point is this function has no business in the core language. It's not in the core language. It's in the gettext extension. -chuck -- I have pointy little boobs! - Jason BEGIN:VCARD VERSION:2.1 N:Daniluk;Cristopher FN:Cristopher Daniluk ORG:Digital Services Network, Inc.;Executive Management TITLE:President CEO NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A TEL;WORK;VOICE:(330) 530-2373 TEL;WORK;VOICE:(800) 845-4822 TEL;CELL;VOICE:(330) 219-4819 TEL;WORK;FAX:(208) 723-6782 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;President;89 West Marshall Avenue=0D=0ASuite A;McDonald;Ohio;44437;United S= tates of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:President=0D=0A89 West Marshall Avenue=0D=0ASuite A=0D=0AMcDonald, Ohio 4443= 7=0D=0AUnited States of America URL;WORK:http://www.dsnet.net/~cris EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20010528T230445Z END:VCARD -- 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]
Re: [PHP-DEV] Woah
At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. -Andrei -- 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]
