Simple de part sa syntaxe : Je connais pas Ruby, donc j'aurai du mal a te dire ... En tout cas, pas comme Perl. Quand je dis simple, ca va avec 1 feature/1 syntaxe. C'est aussi par rapport a la syntaxe Java vs C++.
1 feature / 1 syntaxe : Non :-), pas pour les boucles du moins.
coherent au niveau de la syntaxe : ca n'a jamais ete voulu comme un argument. Il s'agissait de lister un peu les buts de la creation de Nosica. Pas de dire "il est cool mon language, viens-y l'essayer" !! :-)
Quand je dis coherent, ca veut dire que la notation tente d'etre uniforme..
Exemple :
class toto extend A implements B ...
Bon, ben clairement, vaut mieux ecrire
class toto extends A implements B
Ca veut dire aussi que les operateurs ont la meme semantique qu'ils soient utilises sur des types primitifs ou sur des types references.
Exemple :
infix ==() un operateur de comparaison de valeur
infix ~~() un operateur de comparaison d'instance (equals en java)
Souplesse :
En Nosica, tu peux heriter d'une classe et implementer N interfaces.
En java ca devient vite chiant parce que souvent tu es oblige de faire de la delegation a la main.
En Nosica tu peux ecrire :
class Toto implements A, B
{
private AImpl aImpl proxies A; // automatic delegation of interface A to aImpl
private BImpl bImpl proxies B;
public sub f() {
// do something
// and callback on aImpl
aImpl.f();
}
}
public interface A
{
sub g();
sub f();
}
C'est a dire que pour toutes les methodes de A et de B, si elles n'ont pas ete implementees dans Toto, on genere automatiquement les methodes manquantes comme des appels sur aImpl et bImpl.
C'est clair ?
Portable : oui, il s'agit du compilo
Optimise : encore pareil, il ne s'agissait pas d'un argument de vente , mais d'essayer de lister le pourquoi de Nosica : quels en sont les buts.
Au niveau du langage, on a pas vraiment de spec "ecrite". Il y a un vieux document completement obsolete appele Nosica's syntax (http://nosica.ng-market.net/LearningNosica.html(...)).
Il y a beaucoup d'idees qui nous viennent, que l'on etudie et lorsque l'on pense que theoriquement on peut le faire et que la syntaxe retenue est objet et sympa, on la met dans Bugzilla.
Donc, pour repondre a ta question :
- Nosica est un langage objet, et tout est objet.
- Heritage simple, implementation d'interface multiple, delegation automatique (a mon sens, plus sympa que l'heritage multiple, moins bloated, plus efficace, car pas de padding et d'indirection supplementaire)
Classes inner/nested/anonymes
- Pas de meta niveau, mais c'est dans les features enhancement, donc ca y sera un jour
Protection : oui : public/private/protected/package
Granularite : pas de compilation separee. On a un autre concept pour resoudre ce probleme appele NoCoMo. Grosso modo il s'agit d'un bus de communication intra/inter/remote processus. Avec une possibilite de pouvoir faire un link pour virer le bus ... Mais bon, ca c'est un delire qui n'est pas pret de voir le jour
- Nouveaux paradigmes : aliasing de methodes ? delegation automatique ? Auparavant on avait l'overloading sur le type retour(ca marchait bien, mais le plus gros probleme c'est le reporting d'erreur)
- Pas de types natifs dans le compilo. Les types "natifs" sont en fait des types primitifs dans la librairie native. C'est a dire qu'ils sont definis dans la librarie standard comme n'importe quel autre type (net.nosica.lang)
- Possibillite de faire de la genericite partielle et de surcharger une implementation generale par le mecanisme de load des classes.
- proprietes (faire passer un appel de methode pour un field)
- tableaux multi dimensionnels
- Garbage collecting tres simple mais efficace via un reference counting automatique
- Types primitifs (aka valeur : alloue sur la pile). Types references (aka dynamique :alloue sur le tas)
Plus d'autres que j'oublie certainement.
Pour ce qui est de la covariance. J'avoue que j'ai jamais su ce que ca voulait dire. Donc pour ma culture G et pour le prochain qui me posera la question, je veux bien que tu m'explique.
J'avoue qu'on a plus eu une approche pragmatique qu'une approche universitaire en ce qui concerne la creation du langage.
Langage de type utilise. Pareil je vois pas trop de quoi tu parle.
Une instance est un representation memoire d'une classe (qu'elle soit primitive ou reference). Tu peux agreger des classes. Tu peux faire de la genericite sur toutes les classes ...
Vala quelques eclaircissements. J'espere te lire pour que tu m'explique la covariance, et langage de type.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 3.
1 feature / 1 syntaxe : Non :-), pas pour les boucles du moins.
coherent au niveau de la syntaxe : ca n'a jamais ete voulu comme un argument. Il s'agissait de lister un peu les buts de la creation de Nosica. Pas de dire "il est cool mon language, viens-y l'essayer" !! :-)
Quand je dis coherent, ca veut dire que la notation tente d'etre uniforme..
Exemple :
class toto extend A implements B ...
Bon, ben clairement, vaut mieux ecrire
class toto extends A implements B
Ca veut dire aussi que les operateurs ont la meme semantique qu'ils soient utilises sur des types primitifs ou sur des types references.
Exemple :
infix ==() un operateur de comparaison de valeur
infix ~~() un operateur de comparaison d'instance (equals en java)
Souplesse :
En Nosica, tu peux heriter d'une classe et implementer N interfaces.
En java ca devient vite chiant parce que souvent tu es oblige de faire de la delegation a la main.
En Nosica tu peux ecrire :
class Toto implements A, B
{
private AImpl aImpl proxies A; // automatic delegation of interface A to aImpl
private BImpl bImpl proxies B;
public sub f() {
// do something
// and callback on aImpl
aImpl.f();
}
}
public interface A
{
sub g();
sub f();
}
C'est a dire que pour toutes les methodes de A et de B, si elles n'ont pas ete implementees dans Toto, on genere automatiquement les methodes manquantes comme des appels sur aImpl et bImpl.
C'est clair ?
Portable : oui, il s'agit du compilo
Optimise : encore pareil, il ne s'agissait pas d'un argument de vente , mais d'essayer de lister le pourquoi de Nosica : quels en sont les buts.
Au niveau du langage, on a pas vraiment de spec "ecrite". Il y a un vieux document completement obsolete appele Nosica's syntax (http://nosica.ng-market.net/LearningNosica.html(...)).
Il y a beaucoup d'idees qui nous viennent, que l'on etudie et lorsque l'on pense que theoriquement on peut le faire et que la syntaxe retenue est objet et sympa, on la met dans Bugzilla.
Donc, pour repondre a ta question :
- Nosica est un langage objet, et tout est objet.
- Heritage simple, implementation d'interface multiple, delegation automatique (a mon sens, plus sympa que l'heritage multiple, moins bloated, plus efficace, car pas de padding et d'indirection supplementaire)
Classes inner/nested/anonymes
- Pas de meta niveau, mais c'est dans les features enhancement, donc ca y sera un jour
Protection : oui : public/private/protected/package
Granularite : pas de compilation separee. On a un autre concept pour resoudre ce probleme appele NoCoMo. Grosso modo il s'agit d'un bus de communication intra/inter/remote processus. Avec une possibilite de pouvoir faire un link pour virer le bus ... Mais bon, ca c'est un delire qui n'est pas pret de voir le jour
- Nouveaux paradigmes : aliasing de methodes ? delegation automatique ? Auparavant on avait l'overloading sur le type retour(ca marchait bien, mais le plus gros probleme c'est le reporting d'erreur)
- Pas de types natifs dans le compilo. Les types "natifs" sont en fait des types primitifs dans la librairie native. C'est a dire qu'ils sont definis dans la librarie standard comme n'importe quel autre type (net.nosica.lang)
- Possibillite de faire de la genericite partielle et de surcharger une implementation generale par le mecanisme de load des classes.
- proprietes (faire passer un appel de methode pour un field)
- tableaux multi dimensionnels
- Garbage collecting tres simple mais efficace via un reference counting automatique
- Types primitifs (aka valeur : alloue sur la pile). Types references (aka dynamique :alloue sur le tas)
Plus d'autres que j'oublie certainement.
Pour ce qui est de la covariance. J'avoue que j'ai jamais su ce que ca voulait dire. Donc pour ma culture G et pour le prochain qui me posera la question, je veux bien que tu m'explique.
J'avoue qu'on a plus eu une approche pragmatique qu'une approche universitaire en ce qui concerne la creation du langage.
Langage de type utilise. Pareil je vois pas trop de quoi tu parle.
Une instance est un representation memoire d'une classe (qu'elle soit primitive ou reference). Tu peux agreger des classes. Tu peux faire de la genericite sur toutes les classes ...
Vala quelques eclaircissements. J'espere te lire pour que tu m'explique la covariance, et langage de type.
A+