Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un
autre.
La classe dérivée déclare :
protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe
ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ
ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne
fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class
blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il
un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans
des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
no.bcausse.spam
Zouplaz wrote:
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un autre.
La classe dérivée déclare : protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
protected meme package
public different package
peu etre pour l'intropection -- bruno Causse http://perso.wanadoo.fr/othello
Zouplaz <pouet@pouet.com> wrote:
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un
autre.
La classe dérivée déclare :
protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe
ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ
ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne
fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class
blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il
un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans
des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
protected meme package
public different package
peu etre pour l'intropection
--
bruno Causse
http://perso.wanadoo.fr/othello
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un autre.
La classe dérivée déclare : protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
protected meme package
public different package
peu etre pour l'intropection -- bruno Causse http://perso.wanadoo.fr/othello
Isammoc
protected meme package
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour l'héritage... non?
-- Isammoc
protected meme package
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour
l'héritage... non?
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour l'héritage... non?
introspection se sert de l'heritage? -- bruno Causse http://perso.wanadoo.fr/othello
Sébastien
Zouplaz wrote:
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un autre.
La classe dérivée déclare : protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
Je pense que le problème est lié au protected : la classe fille peut accéder aux membres protected de la classe mère mais je ne pense pas que l'inverse marche. Et d'ailleurs ton utilisation de l'introspection me semble plus que douteuse. Pourquoi ne pas déclarer dans la classe mère une méthode protected que les classes filles surchargeraient pour retourner ton "ACT_FILTER" ?
Sébastien
Zouplaz wrote:
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un
autre.
La classe dérivée déclare :
protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe
ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ
ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne
fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class
blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il
un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans
des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
Je pense que le problème est lié au protected : la classe fille peut accéder aux membres protected
de la classe mère mais je ne pense pas que l'inverse marche.
Et d'ailleurs ton utilisation de l'introspection me semble plus que douteuse. Pourquoi ne pas
déclarer dans la classe mère une méthode protected que les classes filles surchargeraient pour
retourner ton "ACT_FILTER" ?
Bonjour, j'ai classe ancêtre dans un package et une classe dérivée dans un autre.
La classe dérivée déclare : protected static final int ACT_FILTER = 2;
Quand les classes sont dans le même package, le constructeur de la classe ancêtre peut, avec l'api reflect, accéder en LECTURE à la valeur du champ ci-dessus.
Par contre, si les deux classes sont dans deux packages différents, ça ne fonctionne plus et j'obtiens à l'exécution l'exception :
Class app.WebAppModule can not access a member of class blogger.BloggerModule with modifiers "protected static final"
Pourquoi le fonctionnement change-t-il en fonction du package ? Et y a-t-il un moyen d'arriver à mes fins ? Sachant que j'utilise ces constantes dans des switch/case
L'introspection c'est mal ? Moui mais c'est bien pratique !
Merci
Je pense que le problème est lié au protected : la classe fille peut accéder aux membres protected de la classe mère mais je ne pense pas que l'inverse marche. Et d'ailleurs ton utilisation de l'introspection me semble plus que douteuse. Pourquoi ne pas déclarer dans la classe mère une méthode protected que les classes filles surchargeraient pour retourner ton "ACT_FILTER" ?
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour l'héritage... non?
introspection se sert de l'heritage?
l'introspection doit (normalement) savoir tous les champs disponibles pour une classe... dont celles qui sont déclaré en protected par les classes parents...
Enfin, c'est mon avis, je n'ai pas eu le temps de trop pousser sur la question.
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour
l'héritage... non?
introspection se sert de l'heritage?
l'introspection doit (normalement) savoir tous les champs disponibles pour
une classe... dont celles qui sont déclaré en protected par les classes
parents...
Enfin, c'est mon avis, je n'ai pas eu le temps de trop pousser sur la
question.
Bah pourtant, si mes souvenirs sont bons, protected c'est justement pour l'héritage... non?
introspection se sert de l'heritage?
l'introspection doit (normalement) savoir tous les champs disponibles pour une classe... dont celles qui sont déclaré en protected par les classes parents...
Enfin, c'est mon avis, je n'ai pas eu le temps de trop pousser sur la question.
-- Isammoc
Zouplaz
Sébastien - :
Je pense que le problème est lié au protected : la classe fille peut accéder aux membres protected de la classe mère mais je ne pense pas que l'inverse marche. Et d'ailleurs ton utilisation de l'introspection me semble plus que douteuse. Pourquoi ne pas déclarer dans la classe mère une méthode protected que les classes filles surchargeraient pour retourner ton "ACT_FILTER" ?
Si l'inverse marche mais uniquement si les deux classes sont dans le même package. Je me demande si le problème n'est pas lié à la combinaison de final static protected. Mais en même temps j'ai pas le choix ...
Remarque je peux aussi faire un essai avec public...
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
Sébastien - seb@seb.seb :
Je pense que le problème est lié au protected : la classe fille peut
accéder aux membres protected de la classe mère mais je ne pense pas
que l'inverse marche. Et d'ailleurs ton utilisation de l'introspection
me semble plus que douteuse. Pourquoi ne pas déclarer dans la classe
mère une méthode protected que les classes filles surchargeraient pour
retourner ton "ACT_FILTER" ?
Si l'inverse marche mais uniquement si les deux classes sont dans le même
package. Je me demande si le problème n'est pas lié à la combinaison de
final static protected. Mais en même temps j'ai pas le choix ...
Remarque je peux aussi faire un essai avec public...
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que
ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe
ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
Je pense que le problème est lié au protected : la classe fille peut accéder aux membres protected de la classe mère mais je ne pense pas que l'inverse marche. Et d'ailleurs ton utilisation de l'introspection me semble plus que douteuse. Pourquoi ne pas déclarer dans la classe mère une méthode protected que les classes filles surchargeraient pour retourner ton "ACT_FILTER" ?
Si l'inverse marche mais uniquement si les deux classes sont dans le même package. Je me demande si le problème n'est pas lié à la combinaison de final static protected. Mais en même temps j'ai pas le choix ...
Remarque je peux aussi faire un essai avec public...
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
Zouplaz
Isammoc - Isammoc.jeux(no-spam)@free.fr :
l'introspection doit (normalement) savoir tous les champs disponibles pour une classe... dont celles qui sont déclaré en protected par les classes parents...
Exact, d'ailleurs le champ est "trouvé" mais c'est la lecture d'une valeur qui pose problème...
Isammoc - Isammoc.jeux(no-spam)@free.fr :
l'introspection doit (normalement) savoir tous les champs disponibles
pour une classe... dont celles qui sont déclaré en protected par les
classes parents...
Exact, d'ailleurs le champ est "trouvé" mais c'est la lecture d'une valeur
qui pose problème...
l'introspection doit (normalement) savoir tous les champs disponibles pour une classe... dont celles qui sont déclaré en protected par les classes parents...
Exact, d'ailleurs le champ est "trouvé" mais c'est la lecture d'une valeur qui pose problème...
Sébastien
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma suggestion ? Tu fais une implémentation par défaut dans la classe mère et les classes qui en ont besoin la surchargent comme il faut. Et c'est beaucoup plus propre que d'aller chercher un champ dans la classe fille.
Sébastien
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que
ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe
ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma suggestion ?
Tu fais une implémentation par défaut dans la classe mère et les classes qui en ont besoin la
surchargent comme il faut. Et c'est beaucoup plus propre que d'aller chercher un champ dans la
classe fille.
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma suggestion ? Tu fais une implémentation par défaut dans la classe mère et les classes qui en ont besoin la surchargent comme il faut. Et c'est beaucoup plus propre que d'aller chercher un champ dans la classe fille.
Sébastien
Zouplaz
Sébastien - :
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma suggestion ? Tu fais une implémentation par défaut dans la classe mère et les classes qui en ont besoin la surchargent comme il faut. Et c'est beaucoup plus propre que d'aller chercher un champ dans la classe fille.
Sébastien
Parce que je ne tiens pas à déclarer dans ma classe ancêtre qui se veut ultra générique des dizaines de méthodes spécifiques au projet en cours...
Sébastien - seb@seb.seb :
Pour ce qui est de ta suggestion, je me sers de l'introspection parce
que ACT_FILTER existe ou pas selon le module (l'instance dérivée de
la classe ancêtre). Chaque module a des "actions" qui lui sont
spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma
suggestion ? Tu fais une implémentation par défaut dans la classe mère
et les classes qui en ont besoin la surchargent comme il faut. Et
c'est beaucoup plus propre que d'aller chercher un champ dans la
classe fille.
Sébastien
Parce que je ne tiens pas à déclarer dans ma classe ancêtre qui se veut
ultra générique des dizaines de méthodes spécifiques au projet en cours...
Pour ce qui est de ta suggestion, je me sers de l'introspection parce que ACT_FILTER existe ou pas selon le module (l'instance dérivée de la classe ancêtre). Chaque module a des "actions" qui lui sont spécifiques.
et bien je ne vois pas pourquoi tu ne pourrais pas utiliser ma suggestion ? Tu fais une implémentation par défaut dans la classe mère et les classes qui en ont besoin la surchargent comme il faut. Et c'est beaucoup plus propre que d'aller chercher un champ dans la classe fille.
Sébastien
Parce que je ne tiens pas à déclarer dans ma classe ancêtre qui se veut ultra générique des dizaines de méthodes spécifiques au projet en cours...
