Ce n'est pas lié au fait que le display est explicite ou non ?
Si "string" existe en tant que type primitif, il parait naturel d'envoyer un message print(string) à l'objet display.
display ne sait traiter que des messages avec des paramètres de type string et n'a alors pas besoin de connaître la structure de l'objet émetteur.
C'est bien le display qui a la responsabilité d'afficher (et qui sait comment faire, cf. GRASP)
display.print("une chaine en tant qu'objet primitif")
Du coup pour s'afficher les objets doivent implémenter un contrat qui est de se décrire sous forme de string en tant que type.
display.print(monobjetpasfocrémentunestring.getString())
A fortiori, si mon objet est une classe containeur "String" avec un contrat on obtient
display.print(mastring.getString())
Si on se met dans un contexte d'interprèteur où le display.print() est sous-entendu on a bien pour afficher
display.print(mastring.getString())
qui s'écrit
mastring.getString()
ou encore
"HelloWorld".puts()
Après, il faudrait confronter ça a des langages ala Smalltalk où il me semble que tout est objet (pas de type primitifs) pour avoir une vision encore plus puriste et qui s'appriche de ruby mais ca revient au même.
On envoie une référence à un objet et on invoque sa méthode getString() dans le corps de la méthode display(). (pas besoin de connaître la structure juste le contrat ou même pas cf. duck typing, exception levée, ...)
Bref tout vient du fait que le display est considéré comme implicite ou non.
[^] # Re: Ahhh enfin ! :-)
Posté par El Titi . En réponse à la dépêche Reia, un langage fortement inspiré de Ruby. Évalué à 2.
Si "string" existe en tant que type primitif, il parait naturel d'envoyer un message print(string) à l'objet display.
display ne sait traiter que des messages avec des paramètres de type string et n'a alors pas besoin de connaître la structure de l'objet émetteur.
C'est bien le display qui a la responsabilité d'afficher (et qui sait comment faire, cf. GRASP)
display.print("une chaine en tant qu'objet primitif")
Du coup pour s'afficher les objets doivent implémenter un contrat qui est de se décrire sous forme de string en tant que type.
display.print(monobjetpasfocrémentunestring.getString())
A fortiori, si mon objet est une classe containeur "String" avec un contrat on obtient
display.print(mastring.getString())
Si on se met dans un contexte d'interprèteur où le display.print() est sous-entendu on a bien pour afficher
display.print(mastring.getString())
qui s'écrit
mastring.getString()
ou encore
"HelloWorld".puts()
Après, il faudrait confronter ça a des langages ala Smalltalk où il me semble que tout est objet (pas de type primitifs) pour avoir une vision encore plus puriste et qui s'appriche de ruby mais ca revient au même.
On envoie une référence à un objet et on invoque sa méthode getString() dans le corps de la méthode display(). (pas besoin de connaître la structure juste le contrat ou même pas cf. duck typing, exception levée, ...)
Bref tout vient du fait que le display est considéré comme implicite ou non.
J'ai réconcilié tout le monde ?