Everything

php

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

php.internals

Pierre Joye

20 years ago

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

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

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

Tex Texin

20 years ago

snipped...

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

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

He says in english... ;-)

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

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

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

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

Regards as well,
tex

Jani Taskinen

20 years ago

On Wed, 14 Sep 2005, Tex Texin wrote:

> ok, so you shouldn't program in french. For others it is fine and works
> better than english.

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

Mike Bretz

20 years ago

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:

> On Wed, 14 Sep 2005, Tex Texin wrote:
>
>> ok, so you shouldn't program in french. For others it is fine and works
>> better than english.
>
>
>     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
>

--
mike peter bretz                        metropolis ag / entwicklung
email:  m.bretz@metropolis-ag.de        heinestraße 72
phone:  +49-7121-348-120                d-72762 reutlingen
fax:    +49-7121-348-111                http://www.metropolis-ag.de/

metropolis ag. creating social internetworks.

Tex Texin

20 years ago

> -----Original Message-----
> From: Jani Taskinen [mailto:sniper@iki.fi]
>
> On Wed, 14 Sep 2005, Tex Texin wrote:
>
> > ok, so you shouldn't program in french. For others it is fine and
> > works better than english.
>
>      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

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

l0t3k

20 years ago

""Tex Texin"" <tex@yahoo-inc.com> wrote in message
news:007501c5b927$31ff5f90$9702a8c0@ds.corp.yahoo.com...

> -----Original Message-----

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

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

Makoto Tozawa

20 years ago

Jani Taskinen wrote:

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

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

Rasmus Lerdorf

20 years ago

Makoto Tozawa wrote:

> Jani Taskinen wrote:
>
>>     Show me one such person please. One that does this using PHP. :)
>>     One that really NEEDS this to be possible..
>
>
> 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?

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

Petar Nedyalkov

20 years ago

On Thursday 15 September 2005 06:12, Rasmus Lerdorf wrote:

> Makoto Tozawa wrote:
> > Jani Taskinen wrote:
> >>     Show me one such person please. One that does this using PHP. :)
> >>     One that really NEEDS this to be possible..
> >
> > 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?
>
> 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.

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.

>
> -Rasmus

--

Cyberly yours,
Petar Nedyalkov
Devoted Orbitel Fan :-)

PGP ID: 7AE45436
PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc
PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Jani Taskinen

20 years ago

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

On Wed, 14 Sep 2005, Rasmus Lerdorf wrote:

>
> Makoto Tozawa wrote:
>> Jani Taskinen wrote:
>>
>>>     Show me one such person please. One that does this using PHP. :)
>>>     One that really NEEDS this to be possible..
>>
>>
>> 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?
>
> 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
>
>

--
Donate @ http://pecl.php.net/wishlist.php/sniper

Wez Furlong

20 years ago

No one is forcing you to upgrade to PHP 6.

--Wez.

On 9/15/05, Jani Taskinen <sniper@iki.fi> wrote:

Jani Taskinen

20 years ago

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

On Thu, 15 Sep 2005, Wez Furlong wrote:

> No one is forcing you to upgrade to PHP 6.
>
> --Wez.
>
> On 9/15/05, Jani Taskinen <sniper@iki.fi> wrote:
>>
>>      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
>>
>> On Wed, 14 Sep 2005, Rasmus Lerdorf wrote:
>>
>>>
>>> Makoto Tozawa wrote:
>>>> Jani Taskinen wrote:
>>>>
>>>>>     Show me one such person please. One that does this using PHP. :)
>>>>>     One that really NEEDS this to be possible..
>>>>
>>>>
>>>> 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?
>>>
>>> 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
>>>
>>>
>>
>> --
>> Donate @ http://pecl.php.net/wishlist.php/sniper
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>

--
Donate @ <http://pecl.php.net/wishlist.php/sniper>
Disclaimer: Donating money may make me happier and friendlier for a limited period!

Tex Texin

20 years ago

> -----Original Message-----
> From: Jani Taskinen [mailto:sniper@iki.fi]

Was:

> Subject: Re: [PHP-DEV] PHP6, Unicode for language functions,
> classes,methods, vars names

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

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:

>
>      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
>
> On Thu, 15 Sep 2005, Wez Furlong wrote:
>
> > No one is forcing you to upgrade to PHP 6.
> >
> > --Wez.
> >
> > On 9/15/05, Jani Taskinen <sniper@iki.fi> wrote:
> >>
> >>      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

snip...

Andi Gutmans

20 years ago

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

At 07:42 AM 9/15/2005, Jani Taskinen wrote:

Pierre Joye

20 years ago

On 9/16/05, Andi Gutmans <andi@zend.com> wrote:

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

I think it was ironic, but why do we not do that now in HEAD?

> 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

The Rasmus list has been wastly approved. I fail to see why we should
not apply some request of this list.

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

The past prooved to me that delaying changes is not a good idea.
Changes _never_ come.

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

Having a code base cleaned could help to convert to migrate ;)

--Pierre

Pierre Joye

20 years ago

On 9/16/05, Andi Gutmans <andi@zend.com> wrote:

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

I think it was ironic, but why do we not do that now in HEAD?

> 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

The Rasmus list has been wastly approved. I fail to see why we should
not apply some request of this list.

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

The past prooved to me that delaying changes is not a good idea.
Changes _never_ come.

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

Having a code base cleaned could help to convert to migrate ;)

--Pierre

Jani Taskinen

20 years ago

On Thu, 15 Sep 2005, Andi Gutmans wrote:

> I don't really see how PHP 6 can support a build without ICU. With the whole

Call that version PHP 7.

> 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

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