Forum Programmation.java règles syntaxiques

• # Convention de nommage

  Posté par Hardy Damien le 27 mai 2005 à 09:46. Évalué à 1.

  

  ça sera plus facile avec cette terminologie pour trouver ce que tu cherches (si tant est que j'ai bien deviné)
  
  http://www.loribel.com/java/normes/nommage.html(...)
  
  Dam

  • [^] # Re: Convention de nommage

    Posté par SoWhat le 27 mai 2005 à 10:30. Évalué à 1.

    

    c'est bien ça que je cherche, merci.
    je vais quand même continuer à chercher un pointeur dans les spec officielles de SUN.

• # Bah

  Posté par neil le 27 mai 2005 à 10:34. Évalué à 2.

  

  C'est les spécifications officielle que tu donnes la.
  Dixit http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.(...)
  
  

  
  Letters and digits may be drawn from the entire Unicode character set, which supports most writing scripts in use in the world today, including the large sets for Chinese, Japanese, and Korean. This allows programmers to use identifiers in their programs that are written in their native languages.
  

  
  
  Donc int é = 0; ça marche !
  

  
  neil@box neil $ javac Test.java
  neil@box neil $ cat Test.java
  public class Test {
  
  public static void main(String[] args) {
  
  int é = 0;
  char e = 'é';
  System.out.println (Character.isJavaIdentifierPart (e));
  }
  }
  neil@box neil $ java Test
  true
  

  • [^] # Re: Bah

    Posté par SoWhat le 27 mai 2005 à 10:56. Évalué à 1.

    

    je viens en effet de lire cette section et c'est bien ce qu'il me faut.
    mais je ne suis pas d'accord avec toi:
    
    en effet,
    

    Letters and digits may be drawn from the entire Unicode character set, which supports most writing scripts in use in the world today, including the large sets for Chinese, Japanese, and Korean. This allows programmers to use identifiers in their programs that are written in their native languages.

    
    
    mais par contre :
    

    Identifier:
    IdentifierChars but not a Keyword or BooleanLiteral or NullLiteral
    
    IdentifierChars:
    JavaLetter
    IdentifierChars JavaLetterOrDigit

    
    
    et là, justement,
    

    The Java letters include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024).

    
    
    donc pour un identifiant, on n'a pas le droit au 'letters' mais seullement au sous ensemble 'JavaLetter'.
    
    et chez moi:
    

    bash-2.05b$ cat ./test.java
    class Test {
    int é = 0;
    public static void main (java.lang.String[] args)
    {}
    }
    bash-2.05b$
    bash-2.05b$ javac ./test.java
    ./test.java:2: illegal character: \65533
    int ? = 0;
    ^
    1 error
    bash-2.05b$

    
    
    En fait, je suis étonné que chez toi ça compile ... c'est quelle version de java ?
    

    bash-2.05b$ java -version
    java version "1.4.2_06"

    • [^] # Re: Bah

      Posté par SoWhat le 27 mai 2005 à 11:00. Évalué à 1.

      

      en fait, j'ai même :
      

      
      bash-2.05b$ cat test.java
      class Test {
      public static void main (java.lang.String[] args)
      {
      char e = 'é';
      System.out.println (Character.isJavaIdentifierPart (e));
      }
      }
      bash-2.05b$ javac test.java
      bash-2.05b$ java Test
      false
      bash-2.05b$
      

    • [^] # Re: Bah

      Posté par neil le 27 mai 2005 à 11:24. Évalué à 2.

      

      Comme tu peux le lire juste en desous dans "Examples of identifiers are:" ils mettent des trucs même en grec :p
      
      Le includes ça veut juste dire que ça inclut mais pas que ça exclut tout le reste.
      
      Perso ça marche aussi bien avec tous mes JDK (1.3, 1.4 et 5.0)
      
      

      
      java version "1.3.1_15"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_15-b01)
      Java HotSpot(TM) Client VM (build 1.3.1_15-b01, mixed mode)
      
      java version "1.5.0_03"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
      Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)
      
      java version "1.4.2-01"
      Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-01)
      Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)
      
      java version "1.4.2_08"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
      Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
      

      
      
      Et même avec GCJ !
      

      
      gcj (GCC) 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)
      

      • [^] # Re: Bah

        Posté par SoWhat le 27 mai 2005 à 11:38. Évalué à 1.

        

        Oki, je viens de comprendre.
        Ca dépend de la valeur de la variable d'environement LC_ALL. Chez moi elle est par défaut à 'C' , et ça ne fonctionne pas. Si je la passe à fr_FR, alors ça fonctionne. C'est nul ce truc :(
        Merci pour ton aide.

        • [^] # Re: Bah

          Posté par Black Fox le 27 mai 2005 à 16:51. Évalué à 1.

          

          La variable d'environnement siginifie que tes fichiers textes doivent être considérés comme de l'ascii, donc je ne vois pas en quoi un parser qui rale en trouvant un caractère européen dans son entrée est annormal.
          
          Si tu envoie du texte cobol dans un compilo fait pour le C il aime pas.
          Si tu envois de l'UTF-8 à un parser et que tu lui dit que c'est de l'ascii il vas râler (L'inverse n'est pas vrai, mais c'est volontaire de la part de l'UTF-8)

    • [^] # Re: Bah

      Posté par neil le 27 mai 2005 à 11:26. Évalué à 2.

      

      int ?

      
      Ça serait pas un problème d'encodage ?
      Essaie avec l'option -encoding.

      • [^] # Re: Bah

        Posté par SoWhat le 27 mai 2005 à 11:56. Évalué à 1.

        

        Comme dit plus, haut, c'est ça. pb d'encodage. avec -encoding iso-8859-1 ça passe.
        Encore merci pour ton aide.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.