Journal Nosicalight: 0.3pre3

Posté par  .
Étiquettes :
0
30
jan.
2004
Bon ben voila une nouvelle version de Nosica.
Nouveauté :
- covariance sur le type retour
- les fields constants peuvent etre initialises dans le constructeur
- la librairie standard s'enrichit d'un net.nosica.containers avec des sequences (Vector, Stack, List) et des containeurs associatifs (TreeMap) tout en générique

Beaucoup de correction de bogues.

J'ai fait un paquet debian, mais vu que j'ai pas de debian je ne sais meme pas si c'est installable. Le paquet rpm s'installe chez moi sans probleme.

Page de la release : http://www.nosica.net/user_zone.php?id=FR_nosicalight-0.3(...)

Pour rappel, Nosica est un langage orienté objet. nosicalight est le compilateur implémentant ce langage.

  • # Re: Nosicalight: 0.3pre3

    Posté par  (site web personnel) . Évalué à 2.

    C'est possible d'avoir la grammaire de nosicaa ?

  • # Re: Nosicalight: 0.3pre3

    Posté par  . Évalué à 2.

    Y'a un truc qui me dérange, dans les choix de conception de ce langage: ça http://www.nosica.net/user_zone.php?id=inheritance(...)

    Je suis plutôt d'accord avec ce qu'a dit l'auteur de « C++ FAQ » là-dessus:

    http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq(...)


    [25.2] I've been told that I should never use multiple inheritance. Is that right?

    Grrrrrrrrr.

    It really bothers me when people think they know what's best for your problem even though they've never seen your problem!! How can anybody possibly know that multiple inheritance won't help you accomplish your goals without knowing your goals?!?!?!?!!!

    Next time somebody tells you that you should never use multiple inheritance, look them straight in the eye and say, "One size does not fit all." If they respond with something about their bad experience on their project, look them in the eye and repeat, slower this time, "One size does not fit all."

    People who spout off one-size-fits-all rules presume to make your design decisions without knowing your requirements. They don't know where you're going but know how you should get there.

    Don't trust an answer from someone who doesn't know the question.

    • [^] # Re: Nosicalight: 0.3pre3

      Posté par  (site web personnel) . Évalué à 2.

      Les plus radicaux ont une vision inverse, le créateur de Java par exemple a un regret : avoir mis le mot clé "extends", s'il avait su il n'aurait utilisé que le mot clé implements :)
      Reste que c'est un point de vu et c'est vrai que dans la plupart des cas on peut se passer de l'héritage et que ça évite pas mal de problème de conception. Mais c'est toujours pareil, il faut faire un choix entre fonctionnalités et sécurité.

      • [^] # Re: Nosicalight: 0.3pre3

        Posté par  . Évalué à 1.

        Oui, ca me tarabuste aussi des fois. Des fois je me dis que l'heritage d'implementation (le extends) c'est la facon la plus sure de faire des bugs.

        Je me dis que si on voyait tous les objets comme des boites noires (par interface), et non pas comme des boites blanches ou grises (heritage d'implementation, et mot clef protected) il y aurait moins de problemes.

        Mais si je fais ca, c'est clair qu'on me dirait que Nosica c'est n'importe quoi. Et puis c'est vrai aussi que dans certains cas (tres rares je trouve) ca peut servir.
        D'ailleurs les cas ou ca peut servir, c'est souvent des cas ou on veut optimiser ... (marrant non ?)

    • [^] # Re: Nosicalight: 0.3pre3

      Posté par  . Évalué à 2.

      Tout a fait d'accord avec lui : "One size does not fit all".

      Lorsque tu cree un langage, tu dois faire des choix. Et c'est mon choix (qui ne plait pas forcement a tout le monde) de dire que l'heritage multiple pose des problemes en terme de design et de performance (les implementations efficaces sont tres compliquees a implementer).

      Sinon, on est d'accord que l'heritage multiple peut servir.
      D'apres mon experience les cas sont quand meme assez rare, surtout lorque tu programmes par interface : tu t'apercois que tu en as encore moins besoin. C'est vrai qu'en C++, les gens ne programment pas de la meme maniere et donc faire de l'heritage multiple parait naturel et ca fait bizarre au debut de n'avoir plus cet outil qui parait indispensable. (je suis programmeur C++ depuis 5 ans, je connais Java depuis 3 ans. Mon boulot de tous les jours c'est C++/QT)

      Pour permettre quand meme aux gens de faire un truc qui y ressemble, on propose ca : http://www.nosica.net/user_zone.php?id=Automatic%20delegations(...) (http://www.nosica.net/user_zone.php?id=FR_Automatic%20delegations(...) pour la version française)

      De toute facon, il faut bien se dire que lorsque tu design un langage, tu dois faire des choix. Tu autorises ca d'un cote, et de l'autre cote tu interdis autre chose. C'est la vie.

      A part l'heritage multiple qui te herisses tu as vu des choses interressantes ? des choses qui te plaises moins ? des precisions a apporter ?

      • [^] # Re: Nosicalight: 0.3pre3

        Posté par  . Évalué à 2.

        A part l'heritage multiple qui te herisses tu as vu des choses interressantes ? des choses qui te plaises moins ? des precisions a apporter ?


        Mhhh... Quelques remarques en vrac (j'ai pas lu la spécification du langage et de la lib standard en intégralité)
        * Intégrer un mécanisme de signal/slot dans le langage, ça roxor des mamans ours
        * Pouvoir retourner plusieurs variables, c'est bien aussi
        * Dommages que les itérateurs aient pas été intégrés directement dans le langage, c'est quand même plus sympa un:

        Vector theVector;
        

        
for i in theVector {
        
	i++;
        
}


        que un

        Vector theVector;
        

        
for (it = theVector.iterate(); it.valid(); it.next()) {
        
	it.value() ++;
        
}


        La seconde manière d'écrire les choses, même si elle est idiomatique, est quand même bien plus lourde et moins lisible.

        Ah oui, tiens, au fait: il n'y a pas de méthode standard pour cloner les objets? Si j'ai une fonction de classement (sort) qui peut opérer sur une collection, mais qui doit effectuer une copie de la collection pour ce faire, comment fais-je? (c'est une vraie question, j'ai pas trouvé ; ) )

  • # Re: Nosicalight: 0.3pre3

    Posté par  . Évalué à 2.

    J'ai fait un paquet debian, mais vu que j'ai pas de debian je ne sais meme pas si c'est installable. Le paquet rpm s'installe chez moi sans probleme.


    Ton paquet ne s'installera pas sur une Debian (x86) normale: tu as donné comme nom d'architecture "i586", alors que une Debian x86 a pour nom d'architecture "i386"; elle considèrera donc que c'est pour une architecture différente.

    Au passage, si ton compilateur est en bytecode java, le nom d'architecture devrait être "all" (sauf si c'est en bytecode natif compilé par gcj? auquel cas il serait bon de préciser sur la page des téléchargements que ce sont des paquets i386, tout le monde n'a pas un pécé)

    • [^] # Re: Nosicalight: 0.3pre3

      Posté par  . Évalué à 1.

      Ah OK. Je pensais que comme les distribs bases sur rpm, la Debian reconnaissait i386, i586 et i686.
      Sinon, le paquet debian et rpm inclus une version compilee via gcj et une version en Java pure lançable avec un script shell.
      Par contre la librairie native pour les executables Nosica est directement compilee a partir du C.

      Donc de toute facon, dans tous les cas, je ne peux pas fournir une architecture "all".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.