Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la
sollicitation de cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une
interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la
sollicitation de cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une
interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la
sollicitation de cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une
interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Je dirais que tout ce qui n'est pas certain (mais pas impossible !) est
compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour cause, le
compilateur l'accepte.
Cela répond-il (au moins partiellement) à ta question ?
Je dirais que tout ce qui n'est pas certain (mais pas impossible !) est
compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour cause, le
compilateur l'accepte.
Cela répond-il (au moins partiellement) à ta question ?
Je dirais que tout ce qui n'est pas certain (mais pas impossible !) est
compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour cause, le
compilateur l'accepte.
Cela répond-il (au moins partiellement) à ta question ?
"Fred" wrote in message
news:Je dirais que tout ce qui n'est pas certain (mais pas impossible !)
est compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour
cause, le compilateur l'accepte.Cela répond-il (au moins partiellement) à ta question ?
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
"Fred" <foleide@libre.france> wrote in message
news:O4pWTBEoHHA.4772@TK2MSFTNGP05.phx.gbl...
Je dirais que tout ce qui n'est pas certain (mais pas impossible !)
est compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour
cause, le compilateur l'accepte.
Cela répond-il (au moins partiellement) à ta question ?
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
"Fred" wrote in message
news:Je dirais que tout ce qui n'est pas certain (mais pas impossible !)
est compilé pour une affectation en late binding, non ?
On peut très bien écrire :
Dim o as Object = ÇaRetourneUnObjet()
o.ExecuteUneMéthode
Même si l'intellisense ne nous aide pas en l'occurrence, et pour
cause, le compilateur l'accepte.Cela répond-il (au moins partiellement) à ta question ?
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
C'est bien ce que j'ai compris, enfin, je crois :-). Le compilateur, dans
ton exemple, ne sait pas que V2 n'implémente pas I, même si toi, tu le
sais !
Donc il va générer du late binding. Et comme la variable V1 est juste
déclarée comme implémentant une interface, elle peut être de n'importe
quel type (comme mon object). Pourquoi alors interdire l'affectation à la
compilation ?
Je pense même qu'on peut trouver un autre cas : imagine que V2, qui est de
type C1, soit en fait une instance d'une classe dérivée de C1, disons C3,
qui elle, implémenterait l'interface I ! (je n'ai pas testé si cette
construction est possible, mais j'en suis quasiment persuadé)
Le fait qu'une classe n'implémente pas explicitement une interface
n'interdit pas le fait qu'une instance de cette classe puisse tout de même
l'implémenter. Je le vois comme un cas particulier de mon exemple (Mon
objet n'implémente pas une interface qui contiendrait la méthode
«ExecuteUneMéthode»). Pour que le compilateur n'accepte pas ta syntaxe, il
faudrait une instruction spécifique du langage pour écrire : C1
n'implémente pas I.
Si on part du principe que tout ce qui n'est pas déclaré est faux, alors
mon écriture n'est plus possible non plus et le late binding n'a plus de
raison d'être.
Suis-je plus clair ?
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
C'est bien ce que j'ai compris, enfin, je crois :-). Le compilateur, dans
ton exemple, ne sait pas que V2 n'implémente pas I, même si toi, tu le
sais !
Donc il va générer du late binding. Et comme la variable V1 est juste
déclarée comme implémentant une interface, elle peut être de n'importe
quel type (comme mon object). Pourquoi alors interdire l'affectation à la
compilation ?
Je pense même qu'on peut trouver un autre cas : imagine que V2, qui est de
type C1, soit en fait une instance d'une classe dérivée de C1, disons C3,
qui elle, implémenterait l'interface I ! (je n'ai pas testé si cette
construction est possible, mais j'en suis quasiment persuadé)
Le fait qu'une classe n'implémente pas explicitement une interface
n'interdit pas le fait qu'une instance de cette classe puisse tout de même
l'implémenter. Je le vois comme un cas particulier de mon exemple (Mon
objet n'implémente pas une interface qui contiendrait la méthode
«ExecuteUneMéthode»). Pour que le compilateur n'accepte pas ta syntaxe, il
faudrait une instruction spécifique du langage pour écrire : C1
n'implémente pas I.
Si on part du principe que tout ce qui n'est pas déclaré est faux, alors
mon écriture n'est plus possible non plus et le late binding n'a plus de
raison d'être.
Suis-je plus clair ?
Salut Fred.
Merci pour cette réponse mais à vrai dire, non, pas tout à fait.
Dans l'exemple que tu prends, on ne peut raisonnablement rien
attendre de mieux du compilateur, puisqu'on ne lui fournit aucune
info. En revanche, dans les deux miens, le compilateur sait que :
1) que V2 est de type C1 (et non object)
2) que C1 n'implémente pas I
3) que C1 ne fournit aucun cast spécifique vers I
A partir de là, je pense qu'il dispose de toutes les informations
nécessaires pour interdire le cast et refuser de compiler.
D'où mon entêtement, non d'une pipe, pourquoi est-ce possible ?? :)
C'est bien ce que j'ai compris, enfin, je crois :-). Le compilateur, dans
ton exemple, ne sait pas que V2 n'implémente pas I, même si toi, tu le
sais !
Donc il va générer du late binding. Et comme la variable V1 est juste
déclarée comme implémentant une interface, elle peut être de n'importe
quel type (comme mon object). Pourquoi alors interdire l'affectation à la
compilation ?
Je pense même qu'on peut trouver un autre cas : imagine que V2, qui est de
type C1, soit en fait une instance d'une classe dérivée de C1, disons C3,
qui elle, implémenterait l'interface I ! (je n'ai pas testé si cette
construction est possible, mais j'en suis quasiment persuadé)
Le fait qu'une classe n'implémente pas explicitement une interface
n'interdit pas le fait qu'une instance de cette classe puisse tout de même
l'implémenter. Je le vois comme un cas particulier de mon exemple (Mon
objet n'implémente pas une interface qui contiendrait la méthode
«ExecuteUneMéthode»). Pour que le compilateur n'accepte pas ta syntaxe, il
faudrait une instruction spécifique du langage pour écrire : C1
n'implémente pas I.
Si on part du principe que tout ce qui n'est pas déclaré est faux, alors
mon écriture n'est plus possible non plus et le late binding n'a plus de
raison d'être.
Suis-je plus clair ?
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
--
Patrice
"Patrice" a écrit dans le message de
news:Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface
I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
--
Patrice
"Patrice" <nospm_contact-ongla@leg-si.com> a écrit dans le message de
news: F6AC9889-C0E1-4FE4-B4B8-A26886925B3B@microsoft.com...
Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface
I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
--
Patrice
"Patrice" a écrit dans le message de
news:Bonjour à tous,
J'ai une question dont j'ai presqe honte après qques années de dev.
dotnet. Quid de l'utilisation des interface et du typage statique ?
Naïvement, j'étais persuadé que le compilateur vérifiait statiquement
l'implémentation d'une interface par un objet lors de la sollicitation de
cette interface sur cet objet.
Exemple : disons que C1 est une classe n'implémentant pas une interface
I.
il semble que ce code soit valide :
dim V1 as I
dim V2 as C1
V1=V2
ou encore :
V1=Ctype(V2, I)
Or on est statiquement certain que ce cast ne marche pas il me semble.
So ??? Tout est permi vraiment ??
Euh un autre Patrice ;-)
Euh un autre Patrice ;-)
Euh un autre Patrice ;-)
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
> "Patrice" <http://www.chez.com/scribe/> wrote in message
news:%Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
> "Patrice" <http://www.chez.com/scribe/> wrote in message
news:%23UIuCdRoHHA.3952@TK2MSFTNGP03.phx.gbl...
Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.
> "Patrice" <http://www.chez.com/scribe/> wrote in message
news:%Ce n'est pas si évident que cela me semble t'il...
Par exemple on pourrait utiliser v2 pour stocker une classe qui hérite de
C1 et qui elle implémente cette interface. On n'est donc pas sûr à priori
que cela ne marchera pas dans aucune circonstance.