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 
(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.


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

Reply via email to