Discussion :

[petitprince]

La solution du TActionList resterait la plus "propre"

Oui, oui et oui
Mais j'ai expliqué plus haut pourquoi je ne souhaite pas utiliser le TActionList
Donc voilà...

Edam je ne comprend toujours pas pourquoi ton code marche pour un TMenuItem, mais pour le TShape c'est normal, il n'a pas de propriété OnClick.
Remplace par un TButton, oui enfin j'ai essayé et ça ne marche pas non plus

[Kaféine]

Sauf qu'en raisonnant POO, elle contrevient à toutes les règles d'héritage : tu transtypes ta classe vers une classe dont elle n'hérite pas !!!

je l'ai peut être omis, mais evidemment il y a un test avant le transtypage. c'est clair que c'est pas inscrit dans le code de la POO mais de là à me mettre un PV pour ça

il y a également la solution avec une interface qui n'a pas été invoquée. puique apparement c'est des composants customisés de petitprince.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 ICliquable = interface [XXX]
  //getter et setter ici ...
  property OnClick: TNotifyEvent read GetOnClick write SetOnClick;
 end;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
var
 CIntf: ICliquable;
begin
 if Supports(FSaveButton, ICliquable, CIntf) then
  CIntf.OnClick := TestHandler;

[Mac LAK]

je l'ai peut être omis, mais evidemment il y a un test avant le transtypage. c'est clair que c'est pas inscrit dans le code de la POO mais de là à me mettre un PV pour ça

En fait, c'est "pire" : avec le RTTI activé, ça plantera. Sans le RTTI, ça passera, mais c'est ultra-dépendant de l'implémentation : ça peut aussi bien passer que planter.

Désolé, "nothing personal" comme on dit, mais ta solution n'est pas correcte... On ne transtype pas vers une classe dont on n'hérite pas, quoi qu'il arrive.

[Kaféine]

En fait, c'est "pire" : avec le RRTI activé, ça plantera. Sans le RTTI, ça passera, mais c'est ultra-dépendant de l'implémentation : ça peut aussi bien passer que planter.

Désolé, "nothing personal" comme on dit, mais ta solution n'est pas correcte... On ne transtype pas vers une classe dont on n'hérite pas, quoi qu'il arrive.

j'avoue je ne te suis plus.
de quel post parles tu?

il n'a jamais été question de transtyper vers une classe dont on hérite pas dans mes posts...

Pour ce qui concerne la solution RTTI je ne vois pas le problème?

[Mac LAK]

j'avoue je ne te suis plus.
de quel post parles tu?

Celui où tu donnes ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
type
  TWinControlAccess = class(TWinControl);
 
TWinControlAccess(FSaveButton).OnClick := SaveProjectEvent;

Le problème, c'est que si (par exemple) ton TButton et ton TWinControlAccess dérivent bien tous les deux de TWinControl, TButton, lui, ne dérive pas de TWinControlAccess. Donc, transtyper vers ce TWinControlAccess est strictement interdit par la POO, et ne peut marcher QUE via un effet de bord hautement dépendant de l'implémentation... Notamment, tu ne peux pas garantir que la VMT de ton TButton sera compatible avec celle de TWinControlAccess sur la propriété OnClick, ce qui pourrait provoquer au mieux une erreur de compilation, au pire une assignation vers quelque chose d'indéterminé à l'exécution.

il n'a jamais été question de transtyper vers une classe dont on hérite pas dans mes posts...

Ben si...

Pour ce qui concerne la solution RTTI je ne vois pas le problème?

Justement : le RTTI, lui, te dira que tu n'hérites PAS de cette classe, essaie avec "TButton.InheritsFrom(TWinControlAccess)", tu verras bien...

[Kaféine]

Je considére TWinControlAccess comme un alias à TWinControl.
je ne connais pas toutes les subtilités de la VMT mais il me semblais avoir lu que celle ci subissait les même mécanismes d'héritage des classes.
J'ai toujours utiliser cette astuce pour accéder au propriété protected d'une classe d'une autre unité sans problème.

Effectivement dans les protocoles, manuelles et autre bible de POO, cette astuce peut être proscrite mais bon il faut savoir braver les interdits, tricher, pour solutionner certains problèmes.

Toutefois, si tu as une méthode plus élégante (même si je trouve celle ci élégante, je sais les goûts et les couleurs), pour accéder au propriétés protected d'une classe d'une autre unité, je suis preneur

Pour ce qui concerne la solution RTTI, la classe importe peu puisque on interroge l'instance d'objet a propos d'une propriété OnClick.
si elle existe on l'assigne sinon on fait rien

Le seul truc qui pourrait eventuellement poser problème est que l'objet a une propriété OnClick n'étant pas du type TNotifyEvent. Dans ce cas je sais pas ce qu'il se passe. Ma curiosité va me pousser à tester.

[Mac LAK]

Je considére TWinControlAccess comme un alias à TWinControl.

Ben justement, non, ce n'est pas le cas... Ce n'est pas un alias, mais un descendant de TWinControl.

je ne connais pas toutes les subtilités de la VMT mais il me semblais avoir lu que celle ci subissait les même mécanismes d'héritage des classes.

Justement : tu ne sais pas (et tu n'as pas à savoir d'ailleurs) comment elle est implémentée. Ce qui est certain, c'est que cela contrevient à toutes les règles d'héritage / polymorphisme de la POO.
Par exemple, qui te garantit que les méthodes publiées sont au même endroit que les méthodes protégées, dans la VMT ? Ou que simplement dériver la classe publiera toujours les éléments protégés ? Ou que le compilateur acceptera toujours un tel cast sans vérifier la chaîne d'héritage ou les informations RTTI ?
Bref, ta méthode "marchotte" sur ta version actuelle de Delphi... Il n'est nullement garanti qu'elle fonctionnera tout le temps, notamment sur les versions supérieures de Delphi.

De plus, cela t'encourage à avoir de mauvaises habitudes à ce niveau, donc cela peut t'empêcher, à terme, de solutionner correctement un problème.

Règle d'or à appliquer constamment : si tu es bloqué à cause d'un élément non-publié, c'est que tu t'es planté au niveau supérieur de ta conception.

J'ai toujours utiliser cette astuce pour accéder au propriété protected d'une classe d'une autre unité sans problème.

Ce qui est MAAAAAL (prendre une voix dramatique pour prononcer "mal")...
Je t'encourage à aller voir cette discussion par exemple pour voir en quoi ça peut être nuisible. C'est du C++, mais c'est vraiment la même chose qu'en Delphi à ce sujet.

Effectivement dans les protocoles, manuelles et autre bible de POO, cette astuce peut être proscrite mais bon il faut savoir braver les interdits, tricher, pour solutionner certains problèmes.

Fais ça dans mon service, sur mes projets, et t'as droit à une crucifixion en direct-live, avec tortures avant/pendant/après...

Toutefois, si tu as une méthode plus élégante (même si je trouve celle ci élégante, je sais les goûts et les couleurs), pour accéder au propriétés protected d'une classe d'une autre unité, je suis preneur

Elle n'est pas "élégante", elle est FAUSSE : c'est crucial que tu le comprennes...

La solution élégante, c'est le TActionList. La solution VRAIMENT idéale, c'est une meilleure conception de la fiche de façon à ne pas avoir besoin d'un tel mic-mac sur les assignations d'évènements...

Pour ce qui concerne la solution RTTI, la classe importe peu puisque on interroge l'instance d'objet a propos d'une propriété OnClick.
si elle existe on l'assigne sinon on fait rien

Le RTTI, c'est aussi répondre à la méthode "InheritsFrom"... Ce que ta méthode ne permet bien sûr pas.

Le seul truc qui pourrait eventuellement poser problème est que l'objet a une propriété OnClick n'étant pas du type TNotifyEvent. Dans ce cas je sais pas ce qu'il se passe. Ma curiosité va me pousser à tester.

D'où l'ActionList, ou la modification de conception de la fiche de façon à ne plus avoir de sac de nœuds au niveau des évènements.

[Kaféine]

Ben justement, non, ce n'est pas le cas... Ce n'est pas un alias, mais un descendant de TWinControl.

Oui elle hérite mais sans modification et je ne crée pas d'instance de TWinControlAccess. un 'alias' ou un 'raccourci' qui sert juste à tromper delphi pour accéder aux propriétés protected de la classe qui est implémentée dans une autre unité.

Il n'est nullement garanti qu'elle fonctionnera tout le temps, notamment sur les versions supérieures de Delphi.

J'ai utilisé delphi professionellement depuis sa version 6 et suivi les différentes versions jusqu'à la 2009, sans aucun problème.

Fais ça dans mon service, sur mes projets, et t'as droit à une crucifixion en direct-live, avec tortures avant/pendant/après...

pendant et aprés je peux comprendre (la torture c'est mal!) mais avant c'est dure !

La solution élégante, c'est le TActionList. La solution VRAIMENT idéale, c'est une meilleure conception de la fiche de façon à ne pas avoir besoin d'un tel mic-mac sur les assignations d'évènements...

Et si je veux accéder à la propriété Font, j'utilise également un TActionList?
Je veux accéder à n'importe quelles propriétés protégées.
Je veux une solution élégante qui me permette de résoudre mon problème à savoir accéder à une propriété quelconque protected même si la classe de base est dans une autre unité.
il se trouve que ici le topic concernait un évênement "OnClick".

[Mac LAK]

Oui elle hérite mais sans modification et je ne crée pas d'instance de TWinControlAccess. un 'alias' ou un 'raccourci' qui sert juste à tromper delphi pour accéder aux propriétés protected de la classe qui est implémentée dans une autre unité.

La question n'est pas sur le fait d'instancer ou pas ta classe, mais sur le fait de la caster avec une classe dont elle ne dérive pas...

Si tu en viens à devoir "tromper" Delphi et la VCL, qui est pourtant d'une rare propreté par rapport à d'autres API OO, c'est que tu as mal conçu ton programme initialement, notamment tes héritages, et/ou que tu n'as pas su utiliser correctement les mécanismes de la VCL et du langage pour faire le boulot "proprement".

J'ai utilisé delphi professionellement depuis sa version 6 et suivi les différentes versions jusqu'à la 2009, sans aucun problème.

Mais tu ne peux pas avoir la moindre garantie sur ce sujet !
Or, si jamais ça change, tu t'imagines le bronx si tu ne respectes pas les règles de POO dans tous tes projets ?? Obligé de te scotcher à une version obsolète de Delphi, ou de tout refondre ?

Et si je veux accéder à la propriété Font, j'utilise également un TActionList?
Je veux accéder à n'importe quelles propriétés protégées.

Mais c'est là le souci : tu n'as justement pas à le faire, si elles sont protégées, c'est pour une bonne raison...

Tu peux aussi publier dans une liste quelconque les propriétés qui t'intéressent, notamment dans l'évènement OnCreate (ou OnShow, ou ce qui convient le mieux), en les ajoutant par référence. Là, c'est correct : c'est l'objet lui-même qui publie une de ses propriétés, ça ne contrevient pas aux règles de POO.

Je veux une solution élégante qui me permette de résoudre mon problème à savoir accéder à une propriété quelconque protected même si la classe de base est dans une autre unité.

Soit tu passes par le RTTI et GetPropInfo, soit tu revois ta conception. Mais y accéder par un gros hack de transtypage, c'est vraiment tout sauf élégant...


Alors OK, je sais que c'est "théorique" tout ça, mais il faut bien voir qu'à force d'utiliser un tel hack dans ton code, tu risques de tirer une drôle de tronche sur d'autres langages OO si jamais tu utilises les mêmes "trucs" : ils risquent soit d'être non-fonctionnels, soit de ne pas passer à la compilation.
Et si tu n'as pas la "mentalité" nécessaire pour contourner proprement, tu vas sécher et te retrouver totalement bloqué...

[Kaféine]

Et si tu n'as pas la "mentalité" nécessaire pour contourner proprement, tu vas sécher et te retrouver totalement bloqué...

Qu'est ce que je dois comprendre? je n'ai pas les capacités intellectuelles pour créer un code propre?

Enfin je reste perplexe, et je me rassure en voyant que je suis pas le seul à utiliser cette astuce, j'ai effectué une recherche dans une librairie tiers que j'utilise (la suite DevExpress pour ne pas les citer), et ils l'utilisent également. Pourtant un éditeur de composants de cette envergure se souci forcément de la maintenabilité de leur librairie, ainsi que du support des différentes versions de delphi. Au niveau code, on a affaire à du lourd (et je le trouve élégant), mais apparement, ils n'ont pas trouvé d'alternative à ce hack non plus...

[Andnotor]

Il n'y a aucun hack là-derrière .

Ce que fait Kaféine pour accéder aux méthodes protégées est de l'héritage le plus basique qui soit.

Même s'il n'instancie pas spécifiquement cette nouvelle classe, elle est parfaitement compatible puisqu'il n'y a aucune nouvelle déclaration. (Et n'en aura jamais)
Exactement le même principe est utilisé pour l'interprétation des paramètres en fonction d'un message Windows. (TMessage, TWMKey, TWMMouse, etc.)

(On pourrait aussi se demander pourquoi le Onclick du TShape n'est pas publié alors que les OnMouseXXX le sont !)

En se qui concerne l'assignation d'un événement défini dans deux classes différentes mais portant le même nom, ben ça dépend uniquement de leur prototype. Tant qu'ils sont compatibles, pas de problème par RTTI...

[Mac LAK]

Qu'est ce que je dois comprendre? je n'ai pas les capacités intellectuelles pour créer un code propre?

Non, plutôt qu'une fois qu'un développeur a trouvé une solution "facile", il n'en cherche habituellement pas d'autre... Et lorsqu'il se retrouve dans l'impossibilité d'appliquer son "astuce", il se retrouve en général bloqué par un phénomène de psychorigidité qui l'empêche de réfléchir "autrement".
Cas hélas très fréquent, j'ai plusieurs collègues dans ce cas par exemple...

Enfin je reste perplexe, et je me rassure en voyant que je suis pas le seul à utiliser cette astuce, j'ai effectué une recherche dans une librairie tiers que j'utilise (la suite DevExpress pour ne pas les citer), et ils l'utilisent également.

Il y a aussi eu des braquages à main armée cette nuit : tu crois que je devrais faire pareil pour augmenter mon salaire ?

Pourtant un éditeur de composants de cette envergure se souci forcément de la maintenabilité de leur librairie, ainsi que du support des différentes versions de delphi.

Si j'étais toi, je ne parierais pas ma vie là-dessus, en tout cas... Au pire, eux, ils ont les moyens de fouiller les mécanismes de la VMT et de refaire un (plus) gros hack pour assurer ce point si jamais Delphi effectue un test du polymorphisme à la compilation. Ce qui n'est sûrement pas ton cas, ni le mien d'ailleurs.

L'idéal serait qu'en cas de cast vers un contrôle ancêtre, l'assignation permette de vérifier (à l'exécution) si la propriété est publiée ou pas : ça passerait à la compilation, et à l'exécution, c'est "boum" si le composant n'a pas implémenté la propriété. Mais ça, c'est du ressort de l'éditeur de Delphi.

Au niveau code, on a affaire à du lourd (et je le trouve élégant), mais apparement, ils n'ont pas trouvé d'alternative à ce hack non plus...

Cela reste un hack, et pour moi c'est tout sauf élégant... J'aurais même tendance à trouver ça plutôt choquant dans un code source.
As-tu lu le topic que je t'ai indiqué précédemment ? Et mieux : as-tu testé le code exemple ?

Il n'y a aucun hack là-derrière .

Ben tiens... Tu castes vers une classe dont tu ne dérives pas, t'appelles ça comment, toi ?

Ce que fait Kaféine pour accéder aux méthodes protégées est de l'héritage le plus basique qui soit.

Non : il change le niveau de protection des propriétés/méthodes, ce qui peut poser d'assez lourds problèmes si jamais tu le fais sur une classe n'ayant pas publié, pour une bonne raison, ladite propriété... Tu peux accéder aux propriétés protégées au sein de la classe elle-même (encore heureux...), mais pas en dehors. Si elles sont protégées, c'est pour une bonne raison.
En l'occurrence, dans Delphi, c'est pour permettre qu'une classe puisse ne PAS implémenter un évènement donné... Et s'il n'est pas implémenté mais que tu l'utilises, tu peux prédire le comportement de l'objet ?

Même s'il n'instancie pas spécifiquement cette nouvelle classe, elle est parfaitement compatible puisqu'il n'y a aucune nouvelle déclaration. (Et n'en aura jamais)

Et qui te garantit que la VMT n'est pas modifiée par cette opération ? Rien...

Exactement le même principe est utilisé pour l'interprétation des paramètres en fonction d'un message Windows. (TMessage, TWMKey, TWMMouse, etc.)

Sauf que là, tu parles d'un cast de structures, qui n'est que l'exact reflet du mécanisme interne de Windows... Et une structure ne possède pas de VMT !!!
Appliquer ce principe à une classe, surtout virtuelle, est dangereux. Cf. l'exemple en C++ du lien précédent...

[Andnotor]

il change le niveau de protection des propriétés/méthodes, ce qui peut poser d'assez lourds problèmes si jamais tu le fais sur une classe n'ayant pas publié, pour une bonne raison, ladite propriété

Si elle ne devait pas être modifiée, elle serait private et non protected. Dans pareil cas, ce serait plutôt une erreur de l'éditeur.

Sauf que là, tu parles d'un cast de structures, qui n'est que l'exact reflet du mécanisme interne de Windows... Et une structure ne possède pas de VMT !!!

Mouais, mais la VMT est un unpacked record, alors...

[Mac LAK]

Si elle ne devait pas être modifiée, elle serait private et non protected. Dans pareil cas, ce serait plutôt une erreur de l'éditeur.

Non, parce qu'un attribut privé reste privé à l'unité implémentant la classe, tandis qu'un attribut protégé peut varier et notamment être hérité depuis une autre unité...

Mouais, mais la VMT est un unpacked record, alors...

Inclus comme un attribut "caché" de la classe (au même titre que Self), et sur lequel tu n'as aucun contrôle...



Inutile de polémiquer davantage de toutes façons : des langages purement OO interdisent ce genre de choses, ce n'est possible en Delphi ou C++ que parcequ'ils sont suffisamment bas niveau pour ça. Cela ne devrait pas être possible, par conséquent, il est bien plus prudent de ne pas utiliser ce genre de hack pour détourner les règles d'héritage...

[Andnotor]

En l'occurrence, dans Delphi, c'est pour permettre qu'une classe puisse ne PAS implémenter un évènement donné... Et s'il n'est pas implémenté mais que tu l'utilises, tu peux prédire le comportement de l'objet ?

Pas plus, pas moins que pour n'importe quelle propriété encapsulée après un transtypage. Mais disons qu'il y a peu de chance d'avoir des surprises avec OnClick.

tandis qu'un attribut protégé peut varier et notamment être hérité depuis une autre unité...

Ou simplement augmenter sa visibilité. C'est ce que nous faisons.

Non, on ne va pas polémiquer, et dans l'ensemble je suis assez d'accord avec toi .

C'est "peut-être" une faille du compilateur, mais elle facilite bien des choses et il serait bête de s'en priver. Maintenant, à chaqu'un de savoir ce qu'il code et de s'assurer de la faisabilité de la chose. Mais déclarer une nouvelle classe n'implémentant rien de nouveau sera toujours 100% compatible avec son ancêtre.

Personnellement, je ne donne même pas un nouveau nom à cette classe mais en hérite simplement une nouvelle du même nom. Ainsi pas besoin de transtypage. (Très pratique pour ne pas avoir besoin d'installer de nouveaux composants dans la palette). Et si quelqu'un fait ceci dans ma société, je lui dirai bravo... Avant, pendant et après ! (Mais pas sûr que je l'augmente )

Et de toute façon par définition, le transtypage est de l'anti POO.

ps: Quant aux limitations des autres compilateurs, je ne fais que du Delphi. Donc je m'en balance .

[Mac LAK]

Pas plus, pas moins que pour n'importe quelle propriété encapsulée après un transtypage. Mais disons qu'il y a peu de chance d'avoir des surprises avec OnClick.

Voir donc TShape, TBevel, et j'en passe...

Non, on ne va pas polémiquer, et dans l'ensemble je suis assez d'accord avec toi .

Le problème étant que même pour simplement "augmenter la visibilité", c'est nuisible : si l'on a besoin de ça, c'est soit que l'on n'a pas complètement assimilé le fonctionnement de la VCL, soit que l'on n'utilise pas les "bons" algos/outils...

C'est "peut-être" une faille du compilateur, mais elle facilite bien des choses et il serait bête de s'en priver. Maintenant, à chaqu'un de savoir ce qu'il code et de s'assurer de la faisabilité de la chose. Mais déclarer une nouvelle classe n'implémentant rien de nouveau sera toujours 100% compatible avec son ancêtre.

Pas "peut-être" : c'est une faille du compilateur et du système RTTI... Et utiliser des failles du compilateur pour effectuer un boulot, c'est une plaie : j'ai des tonnes de code fait sous Visual C++ 6.0 et qui refusent de compiler sous Visual Studio 2008, par exemple, parce que le développeur initial a utilisé un truc & astuce de Tonton Marcel pour pisser son code... Souvent au mépris des recommandations MSDN, d'ailleurs.
Alors quand ça commence à toucher les héritages complexes, les templates et les MFC, ça devient un tel sac de nœuds qu'il est plus simple de tout jeter.

Personnellement, je ne donne même pas un nouveau nom à cette classe mais en hérite simplement une nouvelle du même nom. Ainsi pas besoin de transtypage. (Très pratique pour ne pas avoir besoin d'installer de nouveaux composants dans la palette). Et si quelqu'un fait ceci dans ma société, je lui dirai bravo... Avant, pendant et après ! (Mais pas sûr que je l'augmente )

On en reparlera le jour où ça ne marchera plus, et que tu devras soit financer la refonte intégrale du code et/ou te scotcher sur une version obsolète de Delphi à moitié incompatible avec le Windows en cours...
C'est du vécu, avec Visual C++ 6.0 par rapport à XP : t'en fais ce que tu en veux, bien sûr, mais je sais la merde que ça a mis et ce que ça a coûté de la ramasser...

Et de toute façon par définition, le transtypage est de l'anti POO.

Faux, faux et archi-faux : le polymorphisme fait partie intégrante de la POO. Et un cast vers une classe dont on hérite, c'est pas un cast, c'est justement une simple application du polymorphisme.
Or, ce "hack", c'est justement un "vrai" cast, qui n'est PAS dans l'optique du polymorphisme...

ps: Quant aux limitations des autres compilateurs, je ne fais que du Delphi. Donc je m'en balance .

Certes, mais c'est bien aussi d'utiliser plusieurs langages, ça n'apporte que du bon et de l'ouverture à d'autres "mentalités" de développement. Ce n'est jamais néfaste.

Et t'as plein d'autres langages qui ne t'autoriseront JAMAIS à faire ça : tu feras comment, alors, si ta seule solution est de tenter à tout prix de rendre ces propriétés visibles ? Tu modifieras les sources du runtime ?

[Andnotor]

Le transtypage brise justement cette chaîne polymorphique puisqu'on interrompt l'exécution de l'héritage à une classe donnée.

Et t'as plein d'autres langages qui ne t'autoriseront JAMAIS à faire ça : tu feras comment, alors, si ta seule solution est de tenter à tout prix de rendre ces propriétés visibles ? Tu modifieras les sources du runtime ?

Je vais rester fidèle à Delphi !

A+

[Mac LAK]

Le transtypage brise justement cette chaîne polymorphique puisqu'on interrompt l'exécution de l'héritage à une classe donnée.

Non : tu as tout à fait le droit de faire passer un objet pour n'importe lequel de ses ancêtres, à ce stade, ce n'est plus un simple cast.
Un TButton, par exemple, est aussi un TControl, de façon tout à fait légitime. Mais si tu l'utilises comme un TControl, tu as forcément les limitations qui vont avec...

[Kaféine]

http://delphi.about.com/od/oopindelphi/l/aa082603a.htm

Warning!
This is a hack - a very bad OOP technique. There are reasons that components do not expose certain members of their class declaration. Use the technique explained in this article at your own risk.
Note: "a hack" - means that it breaks standard OOP practices. This "hack" works (and will work in future Delphi version) because it relies on a specific Delphi Pascal OOP feature.

c'est bad mais apparement ça marche et marchera toujours

[Mac LAK]

c'est bad

C'est le moins qu'on puisse dire...

mais apparement ça marche

Uniquement en Delphi, et dans aucun autre langage OO, ce qui limite l'application du truc à Tonton Marcel...

et marchera toujours

Si j'étais toi, je ne parierais pas trop là dessus... Rien ne le garantit, car il est toujours possible que Borland décide de verrouiller ceci afin de rendre le langage plus robuste. Pour ma part, j'en serais ravi, j'aimerais un Delphi quasiment aussi rigide que l'Ada.


Après, comme je l'ai dit, tu fais ce que tu veux. Mais, stp, ne conseille pas ce genre d'immondice aux débutants : s'ils tombent sur quelqu'un dans mon genre en entreprise, leur période d'essai va se terminer ... abruptement, on va dire, s'ils jouent à ce genre de trucs sur les hiérarchies objet.
Et sur ce point, ne te leurres pas : t'as nettement plus de gens "rigides" sur le respect des règles de POO, comme moi, que le contraire...