• [^] # Re: Nosicalight version 0.2

    Posté par . En réponse au journal Nosicalight version 0.2. Évalué à 1.

    Delegation ...
    N'oublie pas que j'ai ecrit
    class Toto implements A, B ...
    Donc Toto est toujours un A et Toto est toujours un B.
    Ce qui fait qu'on a l'avantage de l'heritage multiple : on peut heriter de N peres, mais sans les inconvenients : symboles multiples, implementation pas toujours terrible, perte de place a cause du padding, inneficacite a cause des tables a aller consulter ...
    ==> En fait la delegation permet a la fois de repondre au probleme "est un" (mais en terme d'implementation, pas d'interface), et de "contient un" (en terme d'implementation toujours)

    Oui bon, effectivement, les methodes, les boucles ne sont pas objets. Quand je disais tout, je voulais dire les objets... Par exemple en Java et en C++ tu n'as pas la main sur les types natifs. En Nosica tu peux l'avoir.

    Pour le ref counting : oui on est au courant des problemes de cycle !! :-) Ca fait parti des choses que les gens doivent savoir lorsqu'ils codent en Nosica. La plupart des implementation de Lisp dans le temps utilisaient aussi le ref count ... :-)
    Sinon rien ne nous empeche (a part le temps) d'implementer un vrai gc un jour (si ce n'est que je n'aime pas trop les freeze intempestifs)

    En Nosica, tu as This pour Current, mais tu n'a pas la notation "like" ...

    par exemple :
    class Toto<T implements A = AImpl>
    {
    This someFunction() { // some code }
    }
    C'est marrant parce que la raison d'etre de This dans Nosica c'est precisement d'eviter les notations lourdes pour aider a la programmation generique.
    Ceci dit je ne vois pas trop pourquoi ca va rendre inutile la genericite ...