Everything

php

PHP6, Unicode for language functions, classes, methods, vars names

php.internals

Pierre Joye

20 years ago

Hello,

Do we really want to support unicode for functions, classes, methods
and variables names?

I really like to have unicode for comments (// /* */) and inside quotes.

But having:
<?php
function unicode_ist_nicht_süß(){}
function Unicode_не_хорош() {}
?>

is not something I like to see. For language constructs, I would
really like to have only ASCII support...

Regards,

--Pierre

Ondrej Ivanič

20 years ago

Pierre Joye wrote:

>
> is not something I like to see. For language constructs, I would
> really like to have only ASCII support...

This suff works in php4,5:

<?php

function zmaž($čozmazať) {
echo "mažem $čozmazať\n";
}

zmaž(3);

?>

IMHO, if someone need ...

--
Ondrej Ivanič
(ondrej@kmit.sk)

Pierre Joye

20 years ago

On 9/13/05, Ondrej Ivanič <ondrej@kmit.sk> wrote:
> Pierre Joye wrote:
> >
> > is not something I like to see. For language constructs, I would
> > really like to have only ASCII support...
> 
> This suff works in php4,5:
> 
> <?php
> 
> function zmaž($čozmazať) {
>          echo "mažem $čozmazať\n";
> }
> 
> zmaž(3);
> 
> ?>
> 
> IMHO, if someone need ...

I know, that's why I say: PHP6.

--Pierre

Ondrej Ivanič

20 years ago

Pierre Joye wrote:

> On 9/13/05, Ondrej Ivanič <ondrej@kmit.sk> wrote:
>
>>IMHO, if someone need ...
>
> I know, that's why I say: PHP6.

Another constraint? why?

1) It's a BC break (... which impact 1 or 2 users? :) )
2) PHP can be scripting engine in learning programs for children ( like
this: http://www.input.sk/slogo/ ). For children is better to write
"programs" in their native language.

--
Ondrej Ivanič
(ondrej@kmit.sk)

Derick Rethans

20 years ago

On Tue, 13 Sep 2005, Ondrej Ivanič wrote:

> Pierre Joye wrote:
> > On 9/13/05, Ondrej Ivanič <ondrej@kmit.sk> wrote:
> >
> > >IMHO, if someone need ...
> >
> > I know, that's why I say: PHP6.
>
> Another constraint? why?
>
> 1) It's a BC break (... which impact 1 or 2 users? :) )

Actually, I saw this in use in a couple of generic apps, where the
french coders thought it was nice to use the ? (in utf8) in their
function names.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Jani Taskinen

20 years ago

On Tue, 13 Sep 2005, Pierre Joye wrote:

> Do we really want to support unicode for functions, classes, methods
> and variables names?

No. I don't need unicode at all, but if I ever would need it,
it would be enough if I can store it in variables.

(which I can do already, without any fancy ICU)

> I really like to have unicode for comments (// /* */) and inside quotes.

Isn't that possible already? Even in PHP 4?

> But having:
> <?php
> function unicode_ist_nicht_süß(){}
> function Unicode_ÿÿÿÿ_ÿÿÿÿÿÿÿÿÿÿ() {}
> ?>

Gesündheit.

> is not something I like to see. For language constructs, I would
> really like to have only ASCII support...

+1.

--Jani

Ilia A.

20 years ago

Pierre Joye wrote:

> is not something I like to see. For language constructs, I would
> really like to have only ASCII support...

+1 IMHO language identifiers should be limited to ASCII. Yes you can now
use language specific chars by changing the locale, so that ž, č, ÿ are
taken, but that hardly makes for portable code.

Ilia

Rasmus Lerdorf

20 years ago

Ilia Alshanetsky wrote:

> Pierre Joye wrote:
>
>>is not something I like to see. For language constructs, I would
>>really like to have only ASCII support...
>
>
> +1 IMHO language identifiers should be limited to ASCII. Yes you can now
> use language specific chars by changing the locale, so that ž, č, ÿ are
> taken, but that hardly makes for portable code.

What do you mean?  Why wouldn't it be portable?  Because you can't read
it?  It will still run.  Limiting identifiers to ASCII is an artificial
limitation as far as I am concerned.  I see no reason for it.  It's not
as if people are going to suddenly write code for distribution with all
sorts of weird unicode identifiers.  We support high-ascii today and you
never see those in public code.  Java has had unicode identifiers
forever as well, and it doesn't seem to be a problem for them.

For people writing localized code it is very nice to be able to use
descriptive identifiers in their own character set.  It makes it much
easier to understand the code for them.

-Rasmus

Andrei Zmievski

20 years ago

Yep, what Rasmus said.

-Andrei

On Sep 13, 2005, at 6:25 AM, Rasmus Lerdorf wrote:

Andi Gutmans

20 years ago

Me too...

At 09:16 AM 9/13/2005, Andrei Zmievski wrote:

Tex Texin

20 years ago

+١  (Arabic 1)

Many people that program do not speak english and have difficulty distinguishing, typing, and working with english letters and digits.
English terms and english transliterations of their native language do not work well for them
There is no reason to restrict identifiers to English letters and digits, just because they are handy and meaningful to you.
For readability and maintainability of code, it is important to allow people to use meaningful terms. The code in question may never be distributed worldwide, and in fact may only be used by people that know the author's native language.

And fwiw, it reduces the cost of programmers, since hiring someone who knows PHP and can work with English requires more skills than someone who knows PHP and works in the native language. For those of you that love PHP and want to see it remain successful and utilized, localized identifiers makes it more competitive and productive.

My last trip to Asia, in both Korea and Taiwan, I saw translations of books on PHP, so they do learn about PHP in their native language.

Imagine implementing some complicated workflow or other process or algorithm, where each step has a name in the local language, and as a programmer, you have to come up with a meaningless (to you) string to represent it, and having to support that code...

Tex Texin
Internationalization Architect,   Yahoo! Inc.

Pierre Joye

20 years ago

On 9/14/05, Tex Texin <tex@yahoo-inc.com> wrote:

> Imagine implementing some complicated workflow or other process or algorithm, where each
> step has a name in the local language, and as a programmer, you have to come up with a
> meaningless (to you) string to represent it, and having to support that code...

We do that here as we are not native english speakers. I do that since
the 1st day I used a computer, I do that since every songs on the
local radio is in english and  I do that.. oh sorry, off topic.

Well, english is the language of choice for programming because
everyone understands very basic english words. In a world where a lot
of people from many countries have to work together (even in small
local companies) then yes, english is the choice. You have
documentation and inline docs to document them in your native
language, like the books available in korean, french or russian.

Regards,

--Pierre

Tex Texin

20 years ago

Pierre, I am glad it is acceptable to you. What you say does not apply to
everyone.

> Well, english is the language of choice for programming
> because everyone understands very basic english words.

This is just not true. It is true for you, because you make it a requirement
and then you only hire or are satisfied with people that understand english.
But you turn away people that may in fact be better more skilled programmers
because you require english skills.

In a

> world where a lot of people from many countries have to work
> together (even in small local companies) then yes, english is
> the choice.

Also, not true. Many environments where countries work together choose
french because that is common language to them. The French also dominated
parts of the world, and for those areas French is the best alternative.
(Africa, middle east...)

It is selfish and imperialist to insist things must only be done the one way
that english speakers are comfortable with. PHP can be flexible while
companies can insist on only English in their domain if they so choose.
There is no reason to impose that restriction on others.

Other programming languages have already gone this route. If one day we want
to call from PHP to a program that made use of such identifiers, it would be
a shame to not be able to, only because of an unwarranted restriction on the
design.


Tex Texin
Internationalization Architect,   Yahoo! Inc.

Ilia A.

20 years ago

Rasmus Lerdorf wrote:

> What do you mean?  Why wouldn't it be portable?

Well, for one thing code written to use unicode identifiers will
immediately be limited to running on PHP 6 installs. While code using
ASCII identifier with standard "compat" layer could run just fine.

Another reason to only allow ASCII is that now code can be read by
anyone rather then just the people who are familiar with the particular
language user. Heck, some editors do not even allow utf-8 or properly
render some high-ascii chars making those scripts difficult if not
impossible to edit.

Ilia

Rasmus Lerdorf

20 years ago

Ilia Alshanetsky wrote:

> Rasmus Lerdorf wrote:
>
>>What do you mean?  Why wouldn't it be portable?
>
>
> Well, for one thing code written to use unicode identifiers will
> immediately be limited to running on PHP 6 installs. While code using
> ASCII identifier with standard "compat" layer could run just fine.
>
> Another reason to only allow ASCII is that now code can be read by
> anyone rather then just the people who are familiar with the particular
> language user.

This is a choice that should be up to the developer.  If she wants to
share his code with people who don't understand his language and/or
character set, then she should use some common language/character set.
But the language should not force this limitation on her.

-Rasmus

Pierre Joye

20 years ago

On 9/13/05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> This is a choice that should be up to the developer.  If she wants to
> share his code with people who don't understand his language and/or
> character set, then she should use some common language/character set.
> But the language should not force this limitation on her.

The language does put a limitation as it does not provide a way to
show the identifiers in a neutral way. For example ACI 4D (for those
who knows it) did it in the right way. All functions are localized, I
can choose the language I want I will be able to read the identifiers.
But I doubt we will ever do that in PHP :)

Regards,

--Pierre

Sara Golemon

20 years ago

> The language does put a limitation as it
> does not provide a way to show the
> identifiers in a neutral way. For example
> ACI 4D (for those who knows it) did it
> in the right way. All functions are localized,
> I can choose the language I want I will be
> able to read the identifiers. But I doubt we
> will ever do that in PHP :)
>

static function_entry php_espanol_functions[] = {
PHP_FALIAS(secuencia_color, highlight_string, NULL)
PHP_FALIAS(aabierto, fopen, NULL)
PHP_FALIAS(mysql_pregunta, mysql_query, NULL)
etc...etc...etc...
};

-Sara (trying to interject some humor)

Sebastian Nohn

20 years ago

Rasmus Lerdorf wrote:

> This is a choice that should be up to the developer.  If she wants to
> share his code with people who don't understand his language and/or
> character set, then she should use some common language/character set.
> But the language should not force this limitation on her.

Why not display T_PAAMAYIM_NEKUDOTAYIM in hebrew characters if that is so?

Sebastian

Zeev Suraski

20 years ago

At 20:12 13/09/2005, Sebastian Nohn wrote:

>Rasmus Lerdorf wrote:
>
>>This is a choice that should be up to the developer.  If she wants to
>>share his code with people who don't understand his language and/or
>>character set, then she should use some common language/character set.
>>But the language should not force this limitation on her.
>
>Why not display T_PAAMAYIM_NEKUDOTAYIM in hebrew characters if that is so?

Good question, but I think bison doesn't support non ASCII token names :)

Zeev

Derick Rethans

20 years ago

On Tue, 13 Sep 2005, Ilia Alshanetsky wrote:

> Rasmus Lerdorf wrote:
> > What do you mean?  Why wouldn't it be portable?
>
> Well, for one thing code written to use unicode identifiers will
> immediately be limited to running on PHP 6 installs. While code using
> ASCII identifier with standard "compat" layer could run just fine.

I don't see why this is a problem...

> Another reason to only allow ASCII is that now code can be read by
> anyone rather then just the people who are familiar with the particular
> language user. Heck, some editors do not even allow utf-8 or properly
> render some high-ascii chars making those scripts difficult if not
> impossible to edit.

Again, I don't see why this support would be a problem for *you*... if
other people want to use it, let them. It doesn't hurt anybody who
really doesn't use it.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org