Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
ByRef, une absurdité?
Bonjour,
Je cherche une justification à l'utilisation du mot clé ByRef. Je vois ca comme étant une très mauvaise pratique de programmation orienté objet.
Par exemple pour modifier les éléments d'un ListBox, certains programmeurs passe la listbox en référence au lieu d'en valeur.
À mon avis ça rend le code très difficile à maintenir. Des fois ByVal, des fois ByRef.
Pour pas polluer la mémoire pour rien? Foutaise. Y'a un garbage collector.
Y'a-t-il une justification valable?
Absurdité ? Je ne sais pas...
Ce qui est probable, amha, c'est que ce "modificateur" ByRef en VB.NET et ref en C#, est présent dans les deux langages dans un souci de "complétude" sur les sémantiques par valeur/par référence.
Et de fait, il y a des cas d'utilisation importants où ref (ou ByRef) est utile, même si j'ai le sentiment que cela a plutot tendance a survenir dans des couches "basses" (frameworks, interop, etc) plutot qu'applicatives, dans une conception à objet "naturelle".
Cependant, amha a nouveau, je pense que C# est plus "propre" en cela qu'il enonce clairement les contrats et possibilités semantiques pour le programmeur, en forçant ce dernier a exprimer clairement ses objectifs ; en resumant :
C# :
(rien) => semantique par valeur (mais les entités sur la pile a un instant t sont soit des references d'instances, soit des valeurs.. de type valeur justement... ce qui convient a la tres grande majorité des cas d'invocation de méthodes en programmation à objet "canonique", dirons nous)
out => semantique par reference où le fournisseur (l'appelé) s'engage à fournir une valeur à l'entité référencée avant de retourner) ; donc, vérifié par le compilateur
ref => semantique par reference "relachée", où l'appelé ne s'engage pas, à l'inverse de "out", mais où ce sera l'appelant qui aura fourni la valeur par defaut (si l'appelé ne décide d'aucun "effet de bord" avant le retour)
Dans les trois cas, la syntaxe du langage tant sur les signatures que sur les instructions d'invocation avec parametres effectifs force le programmeur a etre consistant (cohérent) entre l'appelé et l'appelant.
VB.NET en revanche n'a que "(rien)" (equivalent à ByVal) ou "ByRef" (qui correspond à ref du C#), sans un "out" digne de ce nom, dans le langage au sens strict.
Je dirais que la syntaxe VB.NET est plus "laxiste" et plus orientée "confort" pour l'appelant, tandis que C# se moque du "confort" (du moins, sur ce sujet) et insiste pour que le programmeur exprime explicitement sa pensée quand la semantique est autre que celle "par défaut" (i.e, par valeur).
Personnellement, sur ce point (et d'autres en fait...), je préfère le choix C#.
Mais bon.. les gouts et les couleurs...
'HTH
Merci pour cette réponse très élaborée et complète.
Tu as raison de dire que ByRef doit être plus utile dans la programmation en back-end que pour du simple applicatif fonctionnel/interface-utilisateurs.
Pour ce qui est du goût, moi, j'aime aussi mieu C#. Malheureusement ce choix m'est imposé à mon emploi.
Je trouve VB.NET un peu trop lyrique, surtout pour ce qui est des fins d'instructions (changement de ligne). Pas de commentaires non plus sur le mot clé "With / End-With".
Lyrique : "...Ouvrages en vers qui sont faits pour être chantés ou propres à être mis en musique, tels que les cantates, les chansons, les opéras..." (extrait de la définition du Wiktionnaire).Envoyé par whorian
Perso, j'aurais plutôt utilisé le terme de verbeux
En C#, quand on appelle une méthode en lui passant un paramètre par référence, on doit faire précéder le paramètre du mot-clé ref : cela permet d'être sûr que le développeur est conscient que la méthode peut modifier la valeur du paramètre.
En VB.NET, le mot clé ByRef n'est indiqué que dans la déclaration ; lors de l'appel de la méthode, c'est implicite. Si bien qu'on peut très bien appeler la méthode sans avoir réalisé qu'elle peut modifier le paramètre... ce qui peut causer de longues heures de débogage et d'arrachage de cheveux à mon avis
Pour moi, ByRef est juste un héritage de VB6 et antérieur, qui a été mal transcrit en VB.NET. La syntaxe de C# sur ce point est beaucoup plus rigoureuse et explicite... mais bon, on va pas transformer cette discussion en débat sur les qualités et défauts des 2 langages, sinon on en finira pas
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
impressionnant ce qu'on lit ici
en vb c'est byval par défaut, donc quand on mets byref c'est volontaire
quand on appelle une sub (ou autre) avec du byref, l'infobulle le précise
de plus on peut mettre une aide xml qui le précise
byref est utile dans certains cas (c'est le seul moyen de remettre une variable distante à nothing)
enfin je ne crois pas qu'il y ait lieu de s'acharner sur lui (byref) ! en tout cas ce n'est pas une absurdité pour moi et loin de là ...
Je ne savais pas que Microsoft et les équipes de Visual Studio étaient infuencés par la Callas et Puccini
le mot ByRef je pense ( à vérifier ) a peut-être son sens et utilité si tu utilises du code unmanaged ou si tu passes à une fonction un paramêtre unmanaged c.a.d une valeur qui fait référence à du code natif.
Si tu appelles une dll système qui renferme des API win32 comme par exemple pour les Hook clavier/souris tu seras obligé d'appeler ByRef ou ByVal selon les cas.
Par exemple, celle pour une fonction de recherche dans des listes d'objets de retourner 2 objets, par exemple avec le "numéro d'immatriculation" retourner l'objet "véhicule" et l'objet "contrat d'assurance".byref offre des possibilités
Répondre avec citation
Partager