Mots réservés en tant que noms ou identificateurs
-
05-07-2019 - |
Question
Existe-t-il un moyen délicat d’utiliser des mots réservés Java en tant que noms de variables, méthodes, classes, interfaces, packages ou énumérations?
La solution
Non, il n'y a pas moyen. C'est pourquoi ils sont étiquetés "réservé".
Autres conseils
Ceci est une question valide. Une telle chose est possible dans d’autres langues. En C #, préfixez l'identificateur avec @
( comme demandé auparavant ); dans Delphi, préfixe avec & amp;
. Mais Java n’offre pas cette fonctionnalité (en partie parce qu’elle n’a pas vraiment besoin d’interagir avec les identifiants définis par d’autres langages comme le fait le monde .Net).
Le plus souvent, ce problème se pose pour "classe", dans ce cas, il est d'usage d'écrire "clazz".
À proprement parler, vous ne pouvez pas le faire, à moins que vous ne mettiez la main sur une implémentation de compilateur qui ne respecte pas les spécifications du langage Java.
Mais là où il y a une volonté, il y a un moyen. Copiez le code suivant dans votre IDE, changez le codage du fichier source en UTF-16 et voilà:
public class HelloWorld {
public static void main(String[] args) {
HelloWorld.nеw();
}
public static void nеw () {
System.out.println("Hello,World");
}
}
Ce code est une classe Java valide et bien formée. Cependant, comme vous l'avez deviné, il existe un petit truc: le '& # 1077;' caractère dans " nouveau " L'identifiant n'appartient pas au jeu de caractères ASCII, il s'agit en fait d'un cyrrilique '& # 1077;' ('YE' prounanced).
La spécification actuelle du langage Java autorise explicitement, et c’est un point important à souligner, l’utilisation de l’Unicode pour nommer les identificateurs. Cela signifie que l’on a la capacité de s’appeler librement pour que ses cours soient en français, en chinois ou en russe s’ils le souhaitent. Il est également possible de mélanger et de faire correspondre les alphabets dans le code. Et historiquement, certaines lettres de l'alphabet latin et d'autres alphabets sont des sosies.
Par conséquent: non, vous ne pouvez pas utiliser les mots réservés comme identificateurs, mais vous pouvez utiliser des identificateurs qui ressemblent exactement aux mots réservés.
Que quelqu'un le fasse ou non, c'est une question totalement différente.
Non, vous ne pouvez pas faire ça. Pour plus d'informations, consultez la page Sections 3.8, 3.9 de JLS
Les séquences de caractères suivantes, formé à partir de lettres ASCII, sont réservé pour une utilisation en tant que mots-clés et ne peut pas être utilisé comme identifiant (§3.8):
Keyword: one of abstract continue for new switch assert default if package synchronized boolean do goto private this break double implements protected throw byte else import public throws case enum instanceof return transient catch extends int short try char final interface static void class finally long strictfp volatile const float native super while
Oui, il y en a. Vous devez utiliser des mots réservés du futur. Comme ce qui s’est passé avec différentes méthodes appelées assert () dans du code antérieur à 1.4.
J'espère que ça aide!
Hein? Pourquoi voudriez-vous faire ça? Vous pouvez les écrire dans l33t, cela va tromper le compilateur.
class cl4ss {
String r3turn() {
return "but why?";
}
}
Je sais que c'est toujours une vieille question, elle pourrait aider quelqu'un.
Cela est possible en utilisant le de GSON. Prise en charge de la dénomination des champs
par exemple.
@SerializedName("new")
private String New;
public String getNew ()
{
return New;
}
public void setNew (String aNew)
{
New = aNew;
}
C’est déjà assez grave que certains langages sensibles à la casse permettent des choses comme celles-ci:
class New;
class Something
{
New makeNew()
{
return new New();
}
}
Mais pourquoi voudriez-vous un jour pouvoir écrire une ligne de code comme celle-ci:
class new;
class Something
{
bool if;
new makeNew()
{
return if ? new new() : null;
}
}
Il suffit de regarder la coloration syntaxique. Même cela devient confus!
Il est impossible d'utiliser des mots réservés avec le compilateur javac .
Techniquement, vous pouvez modifier les noms dans le fichier de classe une fois qu'il est compilé pour qu'il soit comme vous le souhaitez: à ce stade, la VM s'en fiche, car elle ne traite plus le code source. . Je crois que certains obscurcisseurs utilisent cette technique.
PL / 1 (un langage de programmation mainframe IBM des années 1960 qui existe encore de nos jours) exige que si certains mots agissent comme des mots-clés dans certains contextes, tous les mots peuvent être utilisés comme identificateurs. Ce n'est même pas si difficile à faire dans un analyseur si vous voulez être cohérent à ce sujet. Le langage PL / 1 était considéré comme un langage assez volumineux et le comité des langues craignait que de nombreux programmeurs n’apprennent tout, et s’énerveraient ensuite en essayant d’utiliser le mot clé dans une partie qu’ils ne connaissaient pas comme identifiant. . Pour que vous puissiez écrire des choses comme:
IF BEGIN=ELSE THEN CALL=3 ELSE CALL FOO(ENDIF) ENDIF
Comme d'autres l'ont noté ici, la possibilité de le faire n'est pas une recommandation.
Les concepteurs de Java ont décidé que le nombre de mots-clés dans la langue était modeste et ont réservé l'ensemble. Ils ont même réservé 'GOTO', ce qui n'est autorisé dans aucun programme Java réel.
Vous n'êtes pas sûr de ce que vous essayez de faire, mais $ est un caractère valide dans les identifiants; vous pouvez donc le faire, par exemple:
int $ return = 5;
Cela semble un peu bizarre, mais ça marche.
En Scala, vous pouvez utiliser des backticks. Par exemple: myVarialbe.`class`
Si vous devez réellement utiliser un champ / une variable / une méthode portant le même nom qu'un mot réservé, je suggère d'ajouter un trait de soulignement à la fin du nom:
// JPA entity mapping class:
private Boolean void_;
public Boolean getVoid_() { ... }
void setVoid_(Boolean void_) { ... }
C’est un choix plus lisible (IMHO) que d’ajouter des caractères au début du nom (fVoid, aVoid, vVoid, etc.)
Le code ci-dessus est un cas concret qui m'est arrivé, travaillant avec une base de données existante, dans laquelle la table facture
avait un champ nommé void
indiquant si le document avait été annulé ou non.