Re: [PHP-DEV] Woah

[Andi Gutmans]

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 K&R 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 
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]

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

[Hartmut Holzgraefe]

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

[Hartmut Holzgraefe]

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

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

[Zeev Suraski]

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

[Chuck Hagenbuch]

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

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

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

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

[Steve Langasek]

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

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

[Wez Furlong]

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

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

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

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 Km9"m>4opp
> 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

[Cristopher Daniluk]

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

[Cristopher Daniluk]

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

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

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

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

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

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

[George Schlossnagle]

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

[Joey Smith]

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.

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


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

[Hartmut Holzgraefe]

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

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

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

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

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

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

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

[Rodent of Unusual Size]

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

[George Schlossnagle]

I didn't make any suppositions.  I wrote two very simple benchmarking scripts and timed how long they took, as an attempt to measure the overhead of calling userland function aliases.  You're welcome to come to whatever conclusions you want to based on this data.

On Sunday, September 9, 2001, at 12:43 PM, Cristopher Daniluk wrote:
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. 

Try the example I listed with preg_match.  Clearly here one would not expect that the execution speed is twice as long, as (at least intuitively) preg_match does much more woirk than the userland alias.

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. 

The parsing overhead is amortized over a million executions of the code block.

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.


Why not?  It took twice as long to run.  To me that's a cost.  If I was writing a bit of code which did an enormous number of executions of simple userland functions, I would care about this.  If  I'm calling _() or some other function 10 times on a page, then you;re right, I won't care, but if I _do_ for whatever reasoncall a function repeatedly, then it _can_ make a difference.  

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. 

What does this have to do with anything?  The market viability of php implies nothing about the execution speed of function calls (though the latter may be true.)

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.

Thinking about the ramifications of me being right shouldn't make me analytically look at the cost of things?  Whatever.  Fortunately my world view is gruonded enough that I think I can survive the implications of userland function calls having a significant cost.  Instead of sticking my head in the sand, I would rather use this knowledge productively.  To me means when analyzing code efficiency that one should realize that repeated call to userland functions have an intrinsic cost in addtiion to the work done inside a function. 

RE: [PHP-DEV] Woah

[Cristopher Daniluk]

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

Re: [PHP-DEV] Woah

[Zeev Suraski]

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

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

[George Schlossnagle]

>> 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: php-list-
>>> [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: php-list-
>>> [EMAIL PROTECTED]
>>
>>
>> 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.84

Re: [PHP-DEV] Woah

[Sascha Schumann]

> 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 K&R semantics and that
won't change in the foreseeable future.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


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

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

Re: [PHP-DEV] Woah

[Joey Smith]

> >Inconveniencing your long-time users in the name of language purity
> >is, IMHO, just plain stupid.
> 
> To keep us from spiraling down the drain, I'll leave that one unanswered :)

Oops. I already took us down that road.

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.

Zeev, thank you for setting the example on this one.


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

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.



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

[George Schlossnagle]

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:


gstrlen.php:



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

Re: [PHP-DEV] Woah

[Chuck Hagenbuch]

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

[Chuck Hagenbuch]

Quoting Zeev Suraski <[EMAIL PROTECTED]>:

> We can add an E_NOTICE to it

Oh, god, PLEASE don't do that. Some of us actually develop and run our personal
sites (like the one I'm writing this mail with) with error reporting set to
E_ALL. It's good coding practice, helps me write clean code, and if you do this,
I'm going to have to add @ to _every_ gettext call in my code for things to
work, That would be an absolute nightmare. You're also cutting off the option
for users to define an alias, since there'd be just too many versioning issues -
if the function goes away, we can check for it, and if it's not there, alias it.
If there's an E_NOTICE stage in between, we're just fucked.

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

[Anil Madhavapeddy]

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

[Jeroen van Wolffelaar]

> At 01:24 09-09-01, Jeroen van Wolffelaar wrote:
> > > >Exactly the same goes for  > > >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  > > language="php">, etc.  There's a logical place to look for that entry.
> >
> >FYI,
> >
> >'I' added  >etc, because I noticed it wasn't there...
>
> Cool.

Hm, what I wrote was somewhat ambigious, I meant to say that I added 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]

At 01:24 09-09-01, Jeroen van Wolffelaar wrote:
> > >Exactly the same goes for  > >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  > language="php">, etc.  There's a logical place to look for that entry.
>
>FYI,
>
>'I' added etc, because I noticed it wasn't there...

Cool.

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

[Jeroen van Wolffelaar]

> >Exactly the same goes for  >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  language="php">, etc.  There's a logical place to look for that entry.

FYI,

'I' added 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]

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 active by default.  I wouldn't call  pure, would you?  If you
>don't know what it does, where do you start looking?

I don't consider 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 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 , 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 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

[Zeev Suraski]

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

[Sebastian Bergmann]

Rasmus Lerdorf wrote:
>  just like _() is a concession to gettext users.

  And http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

> 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  pure, would you?  If you
don't know what it does, where do you start looking?

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

[Cristopher Daniluk]

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

[Cristopher Daniluk]

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

Re: [PHP-DEV] Woah

[Andrei Zmievski]

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

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

[James Moore]

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:

($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 
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 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 
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 16:28 08-09-01, Rodent of Unusual Size wrote:
>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?

Yes

>   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.  And to determine that _() breaks 
readability of code, *other people's code* that you (a general you, not you 
in person) will have to maintain, I don't have to be a gettext user.  On 
the contrary, the fact I (or Joey, for that matter) came across code with 
_() which confused me completely, is exactly the reason why the statements 
of those who know&use gettext carries less weight.

Fact - there are lots of obscure features in many different language.
Assumption - the people who added these features believed them to be useful 
and not to be obscure, otherwise, they wouldn't have added them.
Moral - the obscurity of such a feature should be determined by the general 
public, and *NOT* by the ones who use it.

>Inconveniencing your long-time users in the name of language purity
>is, IMHO, just plain stupid.

To keep us from spiraling down the drain, I'll leave that one unanswered :)

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

I wouldn't say PHP is a ground breaker in that front, but it certainly 
suffered from a huge legacy of badly named functions in comparison to other 
languages.  I thought we were trying to do something about it, slowly but 
surely.  If a small faction of gettext users can end up leaving the 
mother-of-all-obscure names in the language, I really don't know why we bother.

>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 _()'.

Did you look at the deprecation method I suggested?  Deprecating functions 
is something that we did in the past, and it's a slow process that tries to 
be as harmless as possible.  It's not about starting up vi on gettext.c, 
nuking that alias and committing.

The problem with this whole discussion is that people are mixing two issues:
(a) Is it an ok thing that _() is a PHP function
(b) What can we do about removing it

Note, that most of the people who argued on php-dev argued about (a), for 
all sorts of different reasons.  Sorry, I just don't buy that.  I think 
you're the only one who argued about the practicality of removing it (b).
If we agree that _() is wrong (a), then we can discuss what can be done 
about what can be done to fix it (b).  Perhaps we'll come to the conclusion 
that nothing can be done, but considering we've already deprecated 
functions in the past (yes, in the name of language namespace cleanliness!) 
and we plan to do so in the future, I find this very unlikely.

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

[Jim Jagielski]

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

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

[Stig Sæther Bakken]

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

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

[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

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

> 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

[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

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

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]

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

[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

[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

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

[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

[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

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

[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

[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

[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

[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

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

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

[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

[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

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