[PHP-INTERNALS] PHP6, Unicode for language functions, classes, methods, vars names

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

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.

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

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)
+1.

--Jani

+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

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

Yep, what Rasmus said.

-Andrei

Me too...

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

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

Pierre, I am glad it is acceptable to you. What you say does not apply to
everyone.
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
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.

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

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

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

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)

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

Sebastian

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

Zeev

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

Check the history, every language developement tools which tried to do
it do not support it anymore. Why? For the exact same reasons listed
in this thread.

I'm no pollitician or geostrategy expert, but I do see that english in
a _programming language_ is a good thing. Now, whether people does
speak english or not is not the problem and is not our problem. I can
speak german, french or english while explaining code writing source
codes using english identifiers. And it's the same for many asian or
russian friends with their respective languages. But the only time I
tried to write code in french and I have had to explain it in another
language, it does not work out and it does not work out for the other
with other languages (was german and russian).

I think you are just mixing end user applications requirement (i18n)
and programming language requirements.

Regards,

--Pierre

snipped...
I am not sure why you say this. Java and other languages support
multilingual identifiers.
The newest standards for programming languages are including this feature.
Also markup languages. (XML)

He says in english... ;-)

I can speak german, french or english
ok, so you shouldn't program in french. For others it is fine and works
better than english.

I don't think you have made a case for why it shouldn't be allowed. Only
that you don't like it and it doesn't work for you. But nobody will make you
use non-english terms, so it shouldn't be an issue for you.

Let's agree to disagree. I don't think either of us is shedding much
additional light here now.
Regards as well,
tex

Show me one such person please. One that does this using PHP. :)
One that really NEEDS this to be possible..

I'm with Pierre on this, and I'm not native english speaker either.

--Jani

In addition to the ongoing discussion I like to ask, how far you would
like to go?
If you like unicode support for functions, classes and variable names,
are you willing to do the same for all the php specific function names
and php language specific words? Will "function" and "class" or "return"
(and so on) be translated / available to/in "hebrew" or "russian" only
because I/somebody "can not speak english"? I doubt you will do that!?
The arguments of those people who like to have the support for variable
names should be the same for these words and function names. Why the
arguments do not apply here?

The whole discussion sounds really weird to me because it is focused on
only a very specific part of the language construct... all arguments I
have seen can be summarized as "I do not understand english (well) and
thats why i would like to use my language for variable and function
names". But having support for unicode variable names does not make
anybody be able to program like hell without knowing and understanding
the language specific function names (which I assume will ever be in
english) and identifiers.

I do not think that it is neccessary / important to support unicode here.


mike



Jani Taskinen wrote:

I don't know that many PHP programmers... However, I have worked on programs
in Finnish, and Japanese in other programming languages.

As for "NEEDS" this to be possible, it is a usability thing. For that matter
you don't need English. It used to be that identifiers in Fortran were
limited to 5 characters. There is a reason the limit was lifted, so people
could make more meaningful identifiers.

It is fine you don't want or intend to take advantage of it. (Personally, I
think more than 5 characters in an identifier is too much to type.)
But why do you want to not let others use it if they so desire?
As for why they don't speak up? Well this is an english speaking list...
Make it available and they will come... ;-)

""Tex Texin"" <tex@yahoo-inc.com> wrote in message
news:007501c5b927$31ff5f90$9702a8c0@ds.corp.yahoo.com...
Tex,
this is the one thing i dont understand about people who oppose it. if
they had offered technical arguments ( a valid one maybe performance, for
example), then we could have a rational discussion of pros and cons.
i for one only use English identifiers (though i do speak French), but if
i someone can get a Japanese source-code contract which specifies
identifiers must be Katakana, then more power to us all if PHP is the
language chosen to implement it.


l0t3k

It's impossible to find one as PHP doesn't support it today.

Think of defining a class which encapsulates a database table, and the
table name and column names are in native languages. If PHP restricts
the class and function names to ascii characters, programmers need to
maintain the mapping from the table name to the class name, and the
column name to the set/get function name. Can you guess how painfull
it would be?
Think of a code generator which generates classes from database tables.
What kind of class/function names the code generator could automatically
generate if the programming language restricts the identifiers to ascii
characters?


Makoto

Same goes for SOAP, COM and Java integration. All of these potentially
need to map to unicode identifiers and trying to work around this would
be annoying.

-Rasmus

I totally agree with you all guys. The benefits of having unicode support are
so much and I think ASCII limitations are not good even for PHP's image in
aspect of increasing the popularity of PHP, the number of young developers
using it in their native language, etc. So, I'm two hands up for the unicode
support - we have to keep that line.

Have a nice day.

I don't care about this as long as I can DISABLE it from
my PHP builds (and not be forced to link it with ICU).

--Jani

No one is forcing you to upgrade to PHP 6.

--Wez.

Touché. :)

But I must insist. I want to upgrade at some point.
I might even have use for unicode, at some point. But why can't
I disable it as long as it does not give me anything I need?

On other topic, I want to do the spring cleaning we discussed earlier
already in PHP 5.2. Not the most dramatic ones but the ones everyone
agrees on. Like removing the register_globals..etc.

Or is the only solution to fork?

--Jani

Probably, Because the cost for being able to disable it is greater than the
benefit or the demand.

However, the main reason I write is to suggest the subject change to match
the new topic introduced:
snip...

Jani,

I don't really see how PHP 6 can support a build
without ICU. With the whole core using the ICU
library it's almost like not supporting libC. If
you find a way I'd be happy to hear about it and
discuss but I think it's not realistic.

Regarding spring cleaning, I suggest to relax a
bit. I don't think it should be done before PHP 6
(nor did others including Rasmus suggest that),
and I am still trying to work through that list
and trying to understand where it makes
sense/doesn't make sense to break things. I do
think we have to be careful about some of that
stuff, and as PHP 6 won't be released next month,
and most of those "spring cleaning" patches are
trivial, I don't see a reason to hurry up and not
give some more time. Nothing is gained by doing
it today, and I'm sure Andrei would be happy to
get help from the dev guys on migrating functions
to Unicode which is a lot more work and on the critical path to PHP 6.

Andi

The Rasmus list has been wastly approved. I fail to see why we should
not apply some request of this list.
The past prooved to me that delaying changes is not a good idea.
Changes _never_ come.
Having a code base cleaned could help to convert to migrate ;)

--Pierre

I think most of that list can be implemented but while it's easy to
give a +1 and make the changes, I still want to dive into some of
them more. I've been much busier looking at the Unicode stuff and
5.1.x patches so I didn't have a lot of time to look into it. I think
it's quite reasonable to do that. Don't worry, I won't linger like
you did with some of your promised patches :) (Just kidding).

I doubt you are looking to use PHP 6 in production in the near future...
Andi

No but I live on the edge and dream about a cleaned php-src :-D

--Pierre

The Rasmus list has been wastly approved. I fail to see why we should
not apply some request of this list.
The past prooved to me that delaying changes is not a good idea.
Changes _never_ come.
Having a code base cleaned could help to convert to migrate ;)

--Pierre

I really meant what I said. Like Andi said, PHP 6 won't
be out very soon, but I'd really like to have the cleaned
up PHP, preferrably yesterday. This year is fine too.

And without unicode..

--Jani

Having a PHP6 and a PHP7 next year does not make a lot of sense to me.
As Andi said, we better have to focus us on php6 + unicode and reduce
the momemtum between the last 5.x and 6.

--Pierre

Easy, we'll branch from current PHP_5_1 to PHP_6.
And release PHP 6 as the cleaned up one.

Like you said, the unicode PHP version is not gonna be released for a quite
some time. But I'd really want to see some improvements and cleanups done
before that and not wait another 2 years for that.

The other option is to fork PHP of course. Or maintain my own version
of it, but both of those are not gonna be good for PHP in the long run.
(If I'm forced to maintain my own PHP version, I won't have the energy
to continue working with the "real" PHP..forking is another story)

--Jani

I don't think that's feasible as it makes development even harder.
I don't think Unicode support is that far off. Most of the core work
is done. The more people can help with upgrading the functions the better...
I'm off for the weekend.... Might find some Internet connection at some point.

Andi

I agree here, as far as """core""" will take care of extension
maintainers oppinions and will not push a too early release for non
obvious reason.

From my side, after some cleanup, I should be UC ready pretty soon,
but that is all post pear-1.4.0/5.1.0 stories :)

--Pierre

+ ext/gd