Je sais que c'est une question triviale mais je pensais que c'était clair et
finalement je reçois une erreur...
J'ai une classe Evaluation avec deux contructeurs : public Evaluation() et
public Evaluation( String content )
J'ai deux sous-classes : ClientEvaluation et WorkerEvaluation.
Je pensais que je n'aurai rien de plus à déclarer dans les sous-classes
concernant les constructeurs, je pensais qu'il seraient hérités de
Evaluation, mais non, j'ai du les déclarer car : "The constructor
ClientEvaluation(String) is undefined"...
Comment ça se fait, les constructeurs ne devraient-ils pas être hérités ?
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases ou null pour les objets, je trouve que c'est vraiment enfoncer des portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec this.maVariableInt = 0; // alors que par défaut, un int est initialisé à // zéro.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des
initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases
ou null pour les objets, je trouve que c'est vraiment enfoncer des
portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec
this.maVariableInt = 0; // alors que par défaut, un int est initialisé à
// zéro.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases ou null pour les objets, je trouve que c'est vraiment enfoncer des portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec this.maVariableInt = 0; // alors que par défaut, un int est initialisé à // zéro.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Kupee
Stephane Zuckerman wrote:
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases ou null pour les objets, je trouve que c'est vraiment enfoncer des portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec this.maVariableInt = 0; // alors que par défaut, un int est initialisé à // zéro.
Ah ba non on l'initialise a zero dans la déclaration du champ si on veut etre super clair private int maVariableInt = 0;
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Stephane Zuckerman wrote:
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des
initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases
ou null pour les objets, je trouve que c'est vraiment enfoncer des
portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec
this.maVariableInt = 0; // alors que par défaut, un int est initialisé à
// zéro.
Ah ba non on l'initialise a zero dans la déclaration du champ si on veut
etre super clair
private int maVariableInt = 0;
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop.
Par contre seul les fields sont initialisés, les variables locales
déclarées comme ca
int i;
i n'a pas encore de valeur et est inutilisable.
L'éternel dilemme entre la lisibilité et le perfectionnisme :o
Perso, je mets toujours les super et les this. Pour ce qui est des initialisations, il n'y en a pas 36 possibles, 0 pour les types de bases ou null pour les objets, je trouve que c'est vraiment enfoncer des portes grandes ouvertes.
Ben oui. Mais si on suit la logique jusqu'au bout, on se retrouve avec this.maVariableInt = 0; // alors que par défaut, un int est initialisé à // zéro.
Ah ba non on l'initialise a zero dans la déclaration du champ si on veut etre super clair private int maVariableInt = 0;
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
xav
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop.
Par contre seul les fields sont initialisés, les variables locales
déclarées comme ca
int i;
i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Kupee
xav wrote:
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances
xav wrote:
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment
trop.
Par contre seul les fields sont initialisés, les variables locales
déclarées comme ca
int i;
i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois :
int i;
if (test) {
i = 1;
} else {
i = 2;
}
on est sur d'initialiser i, pas besoin de faire une affectation
supplémentaire, même si ca sera négligeable point de vue performances
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances
pasde.bcausse.spam
xav wrote:
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
non,
comme
Class maClass;
maClass n'est pas forcement null;
-- Bruno Causse http://perso.wanadoo.fr/othello
xav <xav14@free.fr> wrote:
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
non,
comme
Class maClass;
maClass n'est pas forcement null;
-- Bruno Causse http://perso.wanadoo.fr/othello
Fabien Bergeret
Kupee wrote:
xav wrote:
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances Manque de bol, une variable locale doit toujours etre initialisee, car
contrairement a un attribut, elle n'a pas de valeur par defaut ...
Kupee wrote:
xav wrote:
Kupee wrote:
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment
trop.
Par contre seul les fields sont initialisés, les variables locales
déclarées comme ca
int i;
i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois :
int i;
if (test) {
i = 1;
} else {
i = 2;
}
on est sur d'initialiser i, pas besoin de faire une affectation
supplémentaire, même si ca sera négligeable point de vue performances
Manque de bol, une variable locale doit toujours etre initialisee, car
contrairement a un attribut, elle n'a pas de valeur par defaut ...
le faire dans une méthode avec this.maVariableInt = 0; c'est vraiment trop. Par contre seul les fields sont initialisés, les variables locales déclarées comme ca int i; i n'a pas encore de valeur et est inutilisable.
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances Manque de bol, une variable locale doit toujours etre initialisee, car
contrairement a un attribut, elle n'a pas de valeur par defaut ...
Kupee
Fabien Bergeret wrote:
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances
Manque de bol, une variable locale doit toujours etre initialisee, car contrairement a un attribut, elle n'a pas de valeur par defaut ...
Je vois pas ou est le manque de bol ici justement, car dans mon exemple la variable i sera bien initialisée soit dans la clause vrai du if soit dans le else. Tu peux essayer ca compile et ca marche, le compilateur est assez intelligent pour gérer ca.
Fabien Bergeret wrote:
Bof c'est inutile parfois :
int i;
if (test) {
i = 1;
} else {
i = 2;
}
on est sur d'initialiser i, pas besoin de faire une affectation
supplémentaire, même si ca sera négligeable point de vue performances
Manque de bol, une variable locale doit toujours etre initialisee, car
contrairement a un attribut, elle n'a pas de valeur par defaut ...
Je vois pas ou est le manque de bol ici justement, car dans mon exemple
la variable i sera bien initialisée soit dans la clause vrai du if soit
dans le else. Tu peux essayer ca compile et ca marche, le compilateur
est assez intelligent pour gérer ca.
Bof c'est inutile parfois : int i; if (test) { i = 1; } else { i = 2; } on est sur d'initialiser i, pas besoin de faire une affectation supplémentaire, même si ca sera négligeable point de vue performances
Manque de bol, une variable locale doit toujours etre initialisee, car contrairement a un attribut, elle n'a pas de valeur par defaut ...
Je vois pas ou est le manque de bol ici justement, car dans mon exemple la variable i sera bien initialisée soit dans la clause vrai du if soit dans le else. Tu peux essayer ca compile et ca marche, le compilateur est assez intelligent pour gérer ca.
xav
Bruno Causse wrote:
xav wrote:
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
non,
comme
Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Bruno Causse wrote:
xav <xav14@free.fr> wrote:
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
Je suis un peu rouillé en java, mais i vaut 0 même dans ce cas-là, non ?
non,
comme
Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Kupee
xav wrote:
non,
comme Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Si Class maClass; est un champ de ta classe, effectivement il sera null. Si c'est une déclaration dans une méthode, il ne sera rien, même pas null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur (le compilateur compilera pas de toute facon si tu essaye de l'utiliser directement)
xav wrote:
non,
comme
Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Si Class maClass; est un champ de ta classe, effectivement il sera null.
Si c'est une déclaration dans une méthode, il ne sera rien, même pas
null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur
(le compilateur compilera pas de toute facon si tu essaye de l'utiliser
directement)
Si Class maClass; est un champ de ta classe, effectivement il sera null. Si c'est une déclaration dans une méthode, il ne sera rien, même pas null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur (le compilateur compilera pas de toute facon si tu essaye de l'utiliser directement)
xav
Kupee wrote:
xav wrote:
non,
comme Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Si Class maClass; est un champ de ta classe, effectivement il sera null. Si c'est une déclaration dans une méthode, il ne sera rien, même pas null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur (le compilateur compilera pas de toute facon si tu essaye de l'utiliser directement)
Je me rappelais plus de ça :/ En même temps, c'est pas terrible de se reposer sur les valeurs par défaut
Kupee wrote:
xav wrote:
non,
comme
Class maClass;
maClass n'est pas forcement null;
gargl, et comment ?
Si Class maClass; est un champ de ta classe, effectivement il sera null.
Si c'est une déclaration dans une méthode, il ne sera rien, même pas
null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur
(le compilateur compilera pas de toute facon si tu essaye de l'utiliser
directement)
Je me rappelais plus de ça :/
En même temps, c'est pas terrible de se reposer sur les valeurs par défaut
Si Class maClass; est un champ de ta classe, effectivement il sera null. Si c'est une déclaration dans une méthode, il ne sera rien, même pas null, et tu ne pourra pas l'utiliser avant de lui avoir donné une valeur (le compilateur compilera pas de toute facon si tu essaye de l'utiliser directement)
Je me rappelais plus de ça :/ En même temps, c'est pas terrible de se reposer sur les valeurs par défaut
