Oui largement il me semble. Tu noteras quand même que je n'ai pas intégré tout et n'importe quoi du C++ dans Nosica :-)
Encore heureux ! Je me serais sûrement lâché si j'avais vu par exemple des macros ...
Et si je n'ai pas tout introduit, peut etre qu'alors il y a une certaine reflexion non ?
Dont on ne distingue ni les prémisces, ni les buts.
Je m'explique : aussi bien dans la documentation que dans ton message, il n'y a pas de pourquoi (sauf peut-être pour les types primitifs), juste des comment. La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible. On ne trouve dans les différentes adresses que tu donnes que des exemples, mais à aucun moment une justification de la présence de cette fonctionnalité, fort complexe et à mon avis relativement peu utile.
Tiens tres bon exemple de chose que je vais apprendre aujourd'hui ...
C'est quoi un "retour multivarie" ?
Une formulation bancale.
- Est ce qu'il s'agit de surcharge sur le type retour ?
Non, même si cette fonctionnalité aurait, elle, été un vrai plus, absent du reste de Java, ce que je regrette chaque jour.
Si oui, le but etait de permettre des implémentations différentes suivant le type retour. On a essayé, on s'est aperçu que c'etait possible, mais c'etait tres dur de faire du reporting d'erreur lisible. Du coup c'est une fonctionalite qui n'existe plus dans le langage. (depuis à peu près 1 an)
Dommage, c'aurait été très intéressant.
- Est ce qu'il s'agit de pouvoir retourner plusieurs valeurs ?
Oui.
Dans ce cas, je ne comprend pas ce que tu as voulu dire avec ton "retour d'une classe donnée". Creer une classe pour le besoin d'une methode ne me semble pas tres souple. C'est au mieux contraignant.
Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.
Quel est l'interet des mots clefs 'out' en CORBA dans ce cas ? La detection des E/S dans une methode est un indicateur tres puissant pour pouvoir faire des optimisations. (pureté des méthodes, predictibilité des données, ...)
Je suis désolé, mais je ne vois pas le rapport, même si je suis bien d'accord avec toi pour dire que c'est bien pratique de qualifier clairement les entrées d'une méthode.
Exemple donné dans la doc (si si, il faut lire) : http://www.nosica.net/old/LearningNosica.html#operators(...(...)) Ca sert par exemple a implémenter tous les operateurs sur les types primitifs et natifs. Car ces types ne sont pas des First Class Object.
Je ne cherche pas d'exemple, juste une vraie raison. Maintenant que tu me donnes toutes ces informations supplémentaires, effectivement, je comprends l'intérêt de cette surcharge.
Tu m'excuseras, mais essaie de comprendre que passer beaucoup de temps sur un projet, et s'entendre dire par quelqu'un que tu ne connais pas qu'il n'y a pas de réflexion sur le fond du langage ne soit pas tres agréable a entendre.
Ca, je veux bien le comprendre, et je m'excuse si mon ton a paru insultant.
Alors allons-y pour les reflexions sur le fond du langage :
- Une syntaxe claire (je pourrai dire simple, comme Java)
Oui, et c'est un très bon point, je trouve. - Les fonctionalites que je trouve manquer a Java : nottamment la généricite (et non, je ne trouve pas que Java 1.5 apporte vraiment des réponses a ce niveau là, pour moi il s'agit plus d'une rustine qu'une vrai implémentation de la généricité).
Tout dépend si tu considères la généricité comme un point indispensable. Pour ma part, je la treouve utile, mais pas indispensable. Mais aussi la surcharge d'opérateur.
Même remarque, même si cette fois je la trouve franchement superfétatoire. - covariance sur tous les parametres (but depuis le debut meme si on a trouve la solution théorique que récemment)
- pas de types prédéfinis (tous les types, y compris ceux de net.nosica.lang sont entierement redéfinissable par l'utilisateur), ce qui explique pourquoi on a besoin de la distinction entre type primitifs/types references et surcharge d'operateur pour ne citer qu'eux.
C'est pas un peu trop rock'n'roll comme objectif ?
Sinon pour finir, sache que malheureusement je galere enormément à trouver du temps pour m'occuper de Nosica, alors le site oueb et la doc passe en dernier.
Sache aussi que j'accepte volontiers la critique, mais la critique constructive. A ce titre ton deuxieme post est deja plus satisfaisant. Ceci dit il me semble que tu gagnerais a vraiment étudier le langage pour faire une critique plutôt que "parcourir" le site (critique que j'accepterai sans probleme, je ne cherche qu'a améliorer le langage)
Si j'avais le temps, ça me tenterais, mais bien d'autres projets me tentent également, alors ...
[^] # Re: Je prefere Netbeans.
Posté par Nicolas Delsaux . En réponse à la dépêche Eclipse compilé en natif.. Évalué à 2.
Encore heureux ! Je me serais sûrement lâché si j'avais vu par exemple des macros ...
Et si je n'ai pas tout introduit, peut etre qu'alors il y a une certaine reflexion non ?
Dont on ne distingue ni les prémisces, ni les buts.
Je m'explique : aussi bien dans la documentation que dans ton message, il n'y a pas de pourquoi (sauf peut-être pour les types primitifs), juste des comment. La raison de base pour laquelle les opérateurs sont surchargeables n'est ainsi pas lisible. On ne trouve dans les différentes adresses que tu donnes que des exemples, mais à aucun moment une justification de la présence de cette fonctionnalité, fort complexe et à mon avis relativement peu utile.
Tiens tres bon exemple de chose que je vais apprendre aujourd'hui ...
C'est quoi un "retour multivarie" ?
Une formulation bancale.
- Est ce qu'il s'agit de surcharge sur le type retour ?
Non, même si cette fonctionnalité aurait, elle, été un vrai plus, absent du reste de Java, ce que je regrette chaque jour.
Si oui, le but etait de permettre des implémentations différentes suivant le type retour. On a essayé, on s'est aperçu que c'etait possible, mais c'etait tres dur de faire du reporting d'erreur lisible. Du coup c'est une fonctionalite qui n'existe plus dans le langage. (depuis à peu près 1 an)
Dommage, c'aurait été très intéressant.
- Est ce qu'il s'agit de pouvoir retourner plusieurs valeurs ?
Oui.
Dans ce cas, je ne comprend pas ce que tu as voulu dire avec ton "retour d'une classe donnée". Creer une classe pour le besoin d'une methode ne me semble pas tres souple. C'est au mieux contraignant.
Pas du tout ! Avec l'expérience, on constate que les objets retournés par une méthode sont en général utilisés ailleurs, et que si plusieurs valeurs doivent être retournées par une seule méthode, c'est peut-être parce qu'elles font partie d'un même objet, qu'on n'a pas encore vu, et qu'il serait intelligent de fournir.
Quel est l'interet des mots clefs 'out' en CORBA dans ce cas ? La detection des E/S dans une methode est un indicateur tres puissant pour pouvoir faire des optimisations. (pureté des méthodes, predictibilité des données, ...)
Je suis désolé, mais je ne vois pas le rapport, même si je suis bien d'accord avec toi pour dire que c'est bien pratique de qualifier clairement les entrées d'une méthode.
Exemple donné dans la doc (si si, il faut lire) : http://www.nosica.net/old/LearningNosica.html#operators(...(...)) Ca sert par exemple a implémenter tous les operateurs sur les types primitifs et natifs. Car ces types ne sont pas des First Class Object.
Je ne cherche pas d'exemple, juste une vraie raison. Maintenant que tu me donnes toutes ces informations supplémentaires, effectivement, je comprends l'intérêt de cette surcharge.
Tu m'excuseras, mais essaie de comprendre que passer beaucoup de temps sur un projet, et s'entendre dire par quelqu'un que tu ne connais pas qu'il n'y a pas de réflexion sur le fond du langage ne soit pas tres agréable a entendre.
Ca, je veux bien le comprendre, et je m'excuse si mon ton a paru insultant.
Alors allons-y pour les reflexions sur le fond du langage :
- Une syntaxe claire (je pourrai dire simple, comme Java)
Oui, et c'est un très bon point, je trouve.
- Les fonctionalites que je trouve manquer a Java : nottamment la généricite (et non, je ne trouve pas que Java 1.5 apporte vraiment des réponses a ce niveau là, pour moi il s'agit plus d'une rustine qu'une vrai implémentation de la généricité).
Tout dépend si tu considères la généricité comme un point indispensable. Pour ma part, je la treouve utile, mais pas indispensable.
Mais aussi la surcharge d'opérateur.
Même remarque, même si cette fois je la trouve franchement superfétatoire.
- covariance sur tous les parametres (but depuis le debut meme si on a trouve la solution théorique que récemment)
- pas de types prédéfinis (tous les types, y compris ceux de net.nosica.lang sont entierement redéfinissable par l'utilisateur), ce qui explique pourquoi on a besoin de la distinction entre type primitifs/types references et surcharge d'operateur pour ne citer qu'eux.
C'est pas un peu trop rock'n'roll comme objectif ?
Sinon pour finir, sache que malheureusement je galere enormément à trouver du temps pour m'occuper de Nosica, alors le site oueb et la doc passe en dernier.
Sache aussi que j'accepte volontiers la critique, mais la critique constructive. A ce titre ton deuxieme post est deja plus satisfaisant. Ceci dit il me semble que tu gagnerais a vraiment étudier le langage pour faire une critique plutôt que "parcourir" le site (critique que j'accepterai sans probleme, je ne cherche qu'a améliorer le langage)
Si j'avais le temps, ça me tenterais, mais bien d'autres projets me tentent également, alors ...