FAQ
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

Search Discussions

  • Ondrej Ivanič at Sep 13, 2005 at 11:34 am

    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 at Sep 13, 2005 at 11:38 am

    On 9/13/05, Ondrej Ivanič 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č at Sep 13, 2005 at 12:06 pm

    Pierre Joye wrote:
    On 9/13/05, Ondrej Ivanič 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 at Sep 14, 2005 at 12:49 pm

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

    Pierre Joye wrote:
    On 9/13/05, Ondrej Ivanič 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
  • Jani Taskinen at Sep 13, 2005 at 11:46 am

    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 Alshanetsky at Sep 13, 2005 at 1:14 pm

    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 at Sep 13, 2005 at 1:26 pm

    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 at Sep 13, 2005 at 4:16 pm
    Yep, what Rasmus said.

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

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andi Gutmans at Sep 13, 2005 at 10:28 pm
    Me too...
    At 09:16 AM 9/13/2005, Andrei Zmievski wrote:
    Yep, what Rasmus said.

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

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Tex Texin at Sep 14, 2005 at 8:29 am
    +١ (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.



    -----Original Message-----
    From: Andi Gutmans
    Sent: Tuesday, September 13, 2005 3:28 PM
    To: Andrei Zmievski; Rasmus Lerdorf
    Cc: Ilia Alshanetsky; pierre.php@gmail.com; internals
    Subject: Re: [PHP-DEV] PHP6, Unicode for language functions,
    classes,methods, vars names


    Me too...
    At 09:16 AM 9/13/2005, Andrei Zmievski wrote:
    Yep, what Rasmus said.

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

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

  • Pierre Joye at Sep 14, 2005 at 8:38 am

    On 9/14/05, Tex Texin 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 at Sep 14, 2005 at 9:11 am
    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.



    -----Original Message-----
    From: Pierre Joye
    Sent: Wednesday, September 14, 2005 1:38 AM
    To: Tex Texin
    Cc: Andi Gutmans; Andrei Zmievski; Rasmus Lerdorf; Ilia
    Alshanetsky; internals
    Subject: Re: [PHP-DEV] PHP6, Unicode for language functions,
    classes,methods, vars names

    On 9/14/05, Tex Texin 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
  • Ilia Alshanetsky at Sep 13, 2005 at 4:34 pm

    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 at Sep 13, 2005 at 4:39 pm

    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 at Sep 13, 2005 at 4:54 pm

    On 9/13/05, 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.
    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 at Sep 13, 2005 at 5:28 pm

    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 at Sep 13, 2005 at 5:12 pm

    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 at Sep 13, 2005 at 6:35 pm

    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 at Sep 14, 2005 at 12:55 pm

    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
  • Pierre Joye at Sep 14, 2005 at 9:51 pm

    On 9/14/05, Tex Texin 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
    Internationalization Architect, Yahoo! Inc.
  • Tex Texin at Sep 14, 2005 at 10:25 am
    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 at Sep 14, 2005 at 11:02 am

    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 at Sep 14, 2005 at 11:44 am
    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 at Sep 14, 2005 at 12:23 pm

    -----Original Message-----
    From: Jani Taskinen
    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 at Sep 14, 2005 at 4:58 pm
    ""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 at Sep 15, 2005 at 2:57 am

    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 at Sep 15, 2005 at 3:13 am

    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 at Sep 15, 2005 at 7:51 am

    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 at Sep 15, 2005 at 11:29 am
    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 at Sep 15, 2005 at 2:04 pm
    No one is forcing you to upgrade to PHP 6.

    --Wez.
    On 9/15/05, Jani Taskinen 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
  • Jani Taskinen at Sep 15, 2005 at 2:42 pm
    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 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 at Sep 15, 2005 at 7:58 pm

    -----Original Message-----
    From: Jani Taskinen 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 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 at Sep 15, 2005 at 11:36 pm
    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:

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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Sep 15, 2005 at 11:46 pm

    On 9/16/05, Andi Gutmans 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
  • Andi Gutmans at Sep 16, 2005 at 12:05 am
    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
    At 04:46 PM 9/15/2005, Pierre Joye wrote:
    On 9/16/05, Andi Gutmans 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 at Sep 16, 2005 at 12:13 am

    On 9/16/05, Andi Gutmans wrote:
    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).
    Hehe you better have to, as you refuse all of them ;-)
    I doubt you are looking to use PHP 6 in production in the near future...
    No but I live on the edge and dream about a cleaned php-src :-D

    --Pierre
  • Pierre Joye at Sep 16, 2005 at 12:41 am

    On 9/16/05, Andi Gutmans 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 at Sep 16, 2005 at 8:56 am

    On Fri, 16 Sep 2005, Pierre Joye wrote:
    On 9/16/05, Andi Gutmans 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?
    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
  • Pierre Joye at Sep 16, 2005 at 10:34 am

    On 9/16/05, Jani Taskinen wrote:

    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..
    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
  • Jani Taskinen at Sep 16, 2005 at 9:03 am

    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
  • Andi Gutmans at Sep 16, 2005 at 2:43 pm
    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
    At 02:02 AM 9/16/2005, Jani Taskinen wrote:
    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
  • Pierre Joye at Sep 16, 2005 at 2:58 pm

    On 9/16/05, Andi Gutmans wrote:
    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 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
  • Pierre Joye at Sep 16, 2005 at 3:01 pm

    On 9/16/05, Pierre Joye wrote:

    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 :)
    + ext/gd

Related Discussions

People

Translate

site design / logo © 2022 Grokbase