Reprise du message précédent :

 
ben en fait je l'ai aussi, mais pas tout a fait pareil. En gros j'appelle ca des modules (comme Python) et des que tu crées un fichier ca fait un module. Une arborescence de répertoires et fichiers fait une arborescence de modules.
 
mais je peux pas l'utiliser comme dans java pour les droits, puisque dans java, c'est en fonction de la ou tu as déclaré tes classes.
 

mais pour les droits ca n'a pas de sens, vu que 2 packages différents peuvent avoir le même objet (la même réference), et qu'on ne sait pas dans lequel il a été crée.
 
Edit: en fait si, dans le début d'implémentation que j'ai je sais ou il a été crée... je commence a m'embrouiller, la

lorill a écrit a écrit :     je sais pas     c'est pour ca que je veux en faire un, après je saurais   plus serieusement, c'est plus souple, plus rapide a developper, mais aussi plus dangereux.

 
Ca m'a l'air bien dangereux en effet.
Et pas forcément pratique. Quand t'aurras tout plein d'objets, tous plus ou moins bricolé, tu fera comment pour choisir celui à cloner pour la prochaine victime ?
Celui qui sera le plus facile à bricoler, quitte à resaisir du code existant dans d'autres objets, mais qui collent moins bien ?
A moins que t'ai prévu un multi-clonage avec merge de propriété/méthodes qui se ressemblent ?
 
Bon, mais si c'est juste un exercice de style, pourquoi pas !

non, mais rien ne m'empeche de faire un lorill.setAttribute("poster", kadrg.post)
 

ben en fait c'est surtout ca, oui. j'ai pas encore la moindre idée de comment je vais parser, j'ai pas encore défini de syntaxe, mais j'ai déja implémenté le modèle objet, les exceptions, ... et j'arrive a executer des instructions (mais faudra que je le refasse, vu que j'ai limité la syntaxe au minimum pour voir si j'étais capable d'executer du code)

Ah, j'ai trouvé le problème dans mon histoire de package telle que je la présente, c'est l'affectation par référence.
 
Pack1.Toto = System.Object.close ();
Pack2.Tata = Pack1.Toto;
 
Tata et Toto sont deux fois le même objet (modifier un va d'ailleurs répercuter le changement à l'autre), mais situé dans des packages différents.
 
En fait, Es-ce réellement problématique ? Avec mon système, le package n'est qu'une partie du nom, rien de plus, pour pouvoir structurer le nom des objets dans des sous-systèmes pour ne pas tout mettre à plat dans un gros programme.

 
Ok, mais alors il faudra un mécanisme qui vérifie que le code de "kadrg.post" n'utilise pas des attributs inexistant dans lorill. Et même s'ils éxistent rien ne garanti qu'ils ont la bonne signification.

Non, c'est aussi ce que j'ai, d'ou mes diff"érents questions sur les espaces de noms (que j'ai résolu d'ailleurs). C'est juste que je peux pas me baser la dessus pour les permissions d'accès aux attributs

Ca y'aura pas.  
=> fail "no such attribute XXX"

Et pour l'autre objection ?
 
Désolé de faire l'avocat du diable, J'adorre çà  

 
Levée d'exception commande pas comprise, comme en smalltalk.
 
CommandNotUnderstood

si l'attribut existe mais qu'il n'a pas la même signification ? ben deja ca apparait pas dans les exemples, mais j'ai une notion de type (même si elle est relativement faible) donc ca limite un peu, tu est sur que l'attribut concerné a au moins les mêmes attributs que l'objet référence qui sert de type. par contre tu sais pas si les attributs de l'attribut concernés sont du meme type que les attributs de l'objet réference, parce que a l'implémentation ca fait une belle recursion qui finit jamais
 

Mara's dad a écrit a écrit :   Désolé de faire l'avocat du diable, J'adorre çà

non, c'est bien, ca me fait réflechir a des trucs auxquels j'aurai pas forcément pensé.

 
A quoi elle sert cette notion ? Parce que ce langage tel que je le ressent n'a pas de réelle notion de type.

 
a limiter la casse
 

 
c'est pas un typage fort, mais ca apporte un minimum de garantie sur les attributs de l'objet recu

ça a l'air passionnant votre discussion sur la théorie des compilos

je crois qu'on a jamais discuté aussi serieusement que ce soir, il est temps de sortir des vannes a la con, la  

Harkonnen a écrit a écrit : ça a l'air passionnant votre discussion sur la théorie des compilos

sauf que je compile pas  

ça c'est du navigateur génial: si ta page est pas à la denière norme il refuse de l'afficher, trop cool  

Ok, bon au chapitre des questions qui fachent :
 
Je peux donc cloner un objet.
Ensuite je l'utilise un peu, puis je décide de lui ajouter les attributs dont j'ai besoin (éventuellement en les prenant ailleurs). Donc, l'existance des attributs d'un objet est dynamique et fonction du chemin d'éxécution. Il n'est donc pas possible de vérifier au moment de la compilation si l'ajout d'une propriété/methode utilise ou non un attribut inexistant.
 
D'autre part, comment je fait pour avoir Facilement une description exhaustive de mon objet s'il est "bricolé" à partir de bout de code pris à droite et à gauche ?
 
A moins que chaque objet soit statique, qu'il ne soit pas possible d'en créer en cours d'éxécution.

 
1) c pas compilé
 
2) ben a tout moment tu as acces a la liste des attributs

lorill a écrit a écrit :     a limiter la casse   c'est pas un typage fort, mais ca apporte un minimum de garantie sur les attributs de l'objet recu

 
Je ne voit pas l'intêret. N'est-ce pas suffisant de définir le == comme renvoyant true si les deux objet ont les même attributs avec la même valeur, false avec les mêmes attributs et des valeur différentes et levant fail "UncomparableObjects" si ils ont des attributs différents ?
 
Ainsi :  
 

effectivement, y'a très peu de controles au moment de la "compilation" (en fait de la création des structures internes au sein de l'interpréteur). Tout se passe a l'exécution, d'ou le "plus dangereux".
 

chaque objet a un attribut "attributes" qui est en fait un dictionnaire, avec comme clef le nom de l'attribut et comme valeur sa référence.

Je viens de lire que tu compile pas !
 
Ok, donc c'est effectivement très très dangereux comme langage    
 
C'est pour écrire des virus polymorphiques ?
Tu sais ces trucs qui se modifient tout seul en cours d'éxécutions.
Remarque les virus qui plantent c'est pas grave.
Tellement même que du coups t'as même plus à te faire chier à faire une gestion des erreurs...

mareek a écrit a écrit : ça c'est du navigateur génial: si ta page est pas à la denière norme il refuse de l'afficher, trop cool

Non Mozilla n'oblige pas à être à la dernière norme. Il oblige juste à être cohérent : si tu dis que tu fais un document XHTML (donc a priori valide) il s'attend qu'il soit bien formé (et que donc les balises <li> soient bien fermées).
 
Joce peut repasser en HTML 4.01 dans ce cas ça marchera avec Moz.

en fait c'est exactement ce que fait mon isSameFamily(), sauf que j'ai forcé la verification des types lors de l'appel d'une méthode.
 
plusieurs raisons :  
- garantir l'existences de certains attributs de l'objet passé en parametre
- idem pour l'objet en retour
- et le plus important : pour faire taire happyharry

 
Le code qui se modifie en cours d'éxécution, c'est bien(c).

Mara's dad a écrit a écrit : Je viens de lire que tu compile pas !   Ok, donc c'est effectivement très très dangereux comme langage       C'est pour écrire des virus polymorphiques ? Tu sais ces trucs qui se modifient tout seul en cours d'éxécutions. Remarque les virus qui plantent c'est pas grave. Tellement même que du coups t'as même plus à te faire chier à faire une gestion des erreurs...

  nan, tu y es pas, c'est dangereux pour le developpeur parce que s'il fait n'importe quoi, son programme va sortir en erreur avec une exception "no such attribute", mais c'est pas pire qu'un core dump...
 
et ton délire avec les virus, je vois pas ce que ca vient faire la  

 
Dans ton exemple, tu passes un type simple (string), donc tu as un moyen de nommer le type. Mais la notion de family n'a pas de nom, comment donc le nommer pour la déclaration du passage en paramètre ?
 

lorill a écrit a écrit :   et ton délire avec les virus, je vois pas ce que ca vient faire la

 
C'était pour déconner !
 
C'est toi qu'à réclamé un peut moins de sérieux non    
 
Bon, ben continuez bien, moi j'va m'affaler un moment, pi faire un gros DODO !

isSameFamily, c quoi cet anglais là

--greg-- a écrit a écrit : isSameFamily, c quoi cet anglais là

ben toto.isSameFamily(tata) ca me semble correct

--greg-- a écrit a écrit : isSameFamily, c quoi cet anglais là

[+] Quitte à faire un langage original, autant avoir une syntaxe originale. Je propose le klygon ou l'elfique

oops, ben je l'avais mal compris.. un de plus, un de moins  

gm_superstar a écrit a écrit :   [+] Quitte à faire un langage original, autant avoir une syntaxe originale. Je propose le klygon ou l'elfique

 
L'autre jour, j'ai créée une classe java avec un attribut appelé ?

ben en sortie je demande un objet de la même famille que l'objer lorill, c'est pas un type simple.
 
on peut aussi avoir un truc du genre

D'accord.  
 
Bon,  

kadreg a écrit a écrit :   L'autre jour, j'ai créée une classe java avec un attribut appelé ?

ca doit etre génial dans un editeur qui supporte pas l'iso-8859-15
 
pourquoi pas euro, comme tout le monde ?

lorill a écrit a écrit :   ca doit etre génial dans un editeur qui supporte pas l'iso-8859-15

 
Ca fait un gros paté noir dans cet éditeur, mais dans l'AGL après reverse (qui lui supporte bien l'unicode), j'avait bien ?

sur ce,   aussi, j'arriverais jamais a me lever demain sinon

kadreg a écrit a écrit : L'autre jour, j'ai créée une classe java avec un attribut appelé ?

Tu as de la chance qu'on ne bosse pas ensemble : ceux qui utilisent des accents et autres bizarreries dasn leurs classes/méthodes/attributs ont droit à mes plus vives remontrances