Re: [PHP-DEV] Woah

[Chuck Hagenbuch]

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 
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]

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

[Cristopher Daniluk]

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 
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 
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]

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.

On Fri, 7 Sep 2001, Rasmus Lerdorf wrote the following to Zeev Suraski :

> > 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 
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]

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 
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]

At 05:38 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.
>
>Except when it is a known and standard concept.

I don't remember ever coming up with an improved version of the 'Don't use 
obscure single character operators' rule, that includes this exception.

Zeev


-- 
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]

RE: [PHP-DEV] Woah

[Cristopher Daniluk]

I think the more important issue to me is that symbols are generally
operators.

* + / , - .

The list is endless. Couldn't we have just told users to make their own
function _($blah) { return gettext($blah) }? At least it doesn't give a user
the impression of a operation as opposed to a function. Really, PHP has made
strives in the last year toward a consistent naming convention, and has
achieved amazing results. This is just like a slap in the face of hard
effort.

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:47 PM
To: Chuck Hagenbuch
Cc: [EMAIL PROTECTED]
Subject: 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 
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 
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

[Rodent of Unusual Size]

* 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Bruno Mignoni
Email: [EMAIL PROTECTED]
ID:mignoni
Purpose:   Manual Translation

-- 
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]

Re: [PHP-DEV] Woah

[Chuck Hagenbuch]

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 
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]

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 
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]

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

[Rodent of Unusual Size]

* 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 
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

[Cristopher Daniluk]

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 
#define _(String) gettext (String)

instead of merely using `#include '.

-- 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 
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 
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]

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

[Rodent of Unusual Size]

* 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 
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]

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 
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]

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?

On Fri, 7 Sep 2001, Chuck Hagenbuch wrote the following to Joey Smith :

> 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 
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]

Quoting Rodent of Unusual Size <[EMAIL PROTECTED]>:

> 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. :-)

I'd agree with that.

And

-chuck

--
Charles Hagenbuch, <[EMAIL PROTECTED]>
Some fallen angels have their good reasons.

-- 
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]

Re: [PHP-DEV] Woah

[Chuck Hagenbuch]

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

[Cristopher Daniluk]

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 
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 
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]

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

[Cristopher Daniluk]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13210: problens with php and pws

[fefcamel]

From: [EMAIL PROTECTED]
Operating system: win98
PHP version:  4.0.4
PHP Bug Type: Any
Bug description:  problens with php and pws

I tried  to configure php within pws, but it not work. I tried to use with
isapi and cgi configuration, i configured the registry with its path
([HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\Script
Map]
".php"="c:\\inetpub\\scripts\\php\\php.exe ") and nothing happened. I´m
using php 4.04, win 98, pws 4, and when i try to execute any file .php, the
iexplorer returns an internal error (500)
-- 
Edit bug report at: http://bugs.php.net/?id=13210&edit=1


-- 
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]

Re: [PHP-DEV] Woah

[Andrei Zmievski]

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 
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]

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

[Emiliano]

Zeev Suraski wrote:

> 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(),

You can do that in PHP? How?

Emile



-- 
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]

Re: [PHP-DEV] Woah

[Rasmus Lerdorf]

> Zeev Suraski wrote:
>
> > 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(),
>
> You can do that in PHP? How?

You can't.  You missed the dripping sarcasm.

-Rasmus


-- 
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]

Re: [PHP-DEV] Woah

[Egon Schmid]

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

[Emiliano]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] IIS/PWS Config done by PHP

[james]

Hi,

I'm curious to know how PHP configures IIS/PWS to let itself handle all
requests for files ending in .php, etc. How is it done?

Is it the same for IIS and PWS? Is the configuration different for using PHP
as a CGI and as an ISAPI module?

PHP puts a string value under the "Script Map" registry key, but adding just
a new string value for a new file extension doesn't work. So this can't be
it?

Thanks heaps. I've wanted to know this for more than a year now. Posted a
lot of messages to useless Microsoft IIS newsgroups but never got any
response!

James



-- 
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]

[PHP-DEV] Bug #13191: PHP4 docs .chm missing FAQs

[lispenard]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: Documentation problem
Bug description:  PHP4 docs .chm missing FAQs

Hello, 

All the .chm versions of the PHP4 documentation since Thu Jul 26 22:28:30
2001 have been missing the excellent and helpful FAQs.

Is there any reason it's being left out, or just an oversight?  I'd really
like to see it back in the more recent versions.

Thanks for a brilliant job with the documentation to everyone on the docs
team.

-- 
Edit bug report at: http://bugs.php.net/?id=13191&edit=1


-- 
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]

[PHP-DEV] Bug #13191 Updated: PHP4 docs English .chm missing FAQs

[lispenard]

ID: 13191
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Summary: PHP4 docs .chm missing FAQs
Status: Open
Bug Type: Documentation problem
Operating System: 
PHP Version: 4.0.6
New Comment:

Very sorry, I forgot to mention the first time that I was referring to the English 
documentation, .chm format.

Previous Comments:


[2001-09-07 09:55:50] [EMAIL PROTECTED]

Hello, 

All the .chm versions of the PHP4 documentation since Thu Jul 26 22:28:30 2001 have 
been missing the excellent and helpful FAQs.

Is there any reason it's being left out, or just an oversight?  I'd really like to see 
it back in the more recent versions.

Thanks for a brilliant job with the documentation to everyone on the docs team.






Edit this bug report at http://bugs.php.net/?id=13191&edit=1


-- 
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]

[PHP-DEV] Bug #13191 Updated: PHP4 docs .chm missing FAQs

[derick]

ID: 13191
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: Documentation problem
Operating System: 
PHP Version: 4.0.6
New Comment:

Working on it

Previous Comments:


[2001-09-07 10:07:09] [EMAIL PROTECTED]

Very sorry, I forgot to mention the first time that I was referring to the English 
documentation, .chm format.



[2001-09-07 09:55:50] [EMAIL PROTECTED]

Hello, 

All the .chm versions of the PHP4 documentation since Thu Jul 26 22:28:30 2001 have 
been missing the excellent and helpful FAQs.

Is there any reason it's being left out, or just an oversight?  I'd really like to see 
it back in the more recent versions.

Thanks for a brilliant job with the documentation to everyone on the docs team.






Edit this bug report at http://bugs.php.net/?id=13191&edit=1


-- 
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]

[PHP-DEV] Bug #13191 Updated: PHP4 docs .chm missing FAQs

[derick]

ID: 13191
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Documentation problem
Operating System: 
PHP Version: 4.0.6
New Comment:

Will be fixed as soon as they are regenerated (prolly tomorrow).

Derick

Previous Comments:


[2001-09-07 10:13:44] [EMAIL PROTECTED]

Working on it



[2001-09-07 10:07:09] [EMAIL PROTECTED]

Very sorry, I forgot to mention the first time that I was referring to the English 
documentation, .chm format.



[2001-09-07 09:55:50] [EMAIL PROTECTED]

Hello, 

All the .chm versions of the PHP4 documentation since Thu Jul 26 22:28:30 2001 have 
been missing the excellent and helpful FAQs.

Is there any reason it's being left out, or just an oversight?  I'd really like to see 
it back in the more recent versions.

Thanks for a brilliant job with the documentation to everyone on the docs team.






Edit this bug report at http://bugs.php.net/?id=13191&edit=1


-- 
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]