Utilisation des getter/setter ES5 pour des tests null-safe et de la validation de type à la volée

Version imprimable

Voir 40 message(s) de cette discussion en une page

24/11/2014, 13h24
SylvainPV

Ça a aussi été ma première idée, mais ça ne valide que les paramètres settés... S'il y a des paramètres obligatoires qui ne sont pas passés, comme joe.address.work.city, il n'y aura pas d'erreur déclenchée. Je suis donc obligé de valider tout mon modèle récursivement...

N'hésite pas à bidouiller sur mon code, j'ai ouvert ce topic justement pour ça. Je pense que les getter/setter ont un potentiel encore non utilisé, et je suis très curieux de savoir ce qu'on est capable d'en faire.
24/11/2014, 14h04
Invité

salut,

il y a vows qui utilisent get pour créer une api plus 'expressive'.

J'ai pas trop suivi la discussion, mais je trouve dommage de mêler null-safe et validation de données (ca fait un peu effet usine à gaz)

et j'ajoute aussi que je trouve ca byzarre d'avoir un set qui peut créer un arbre dont le noeud parent au noeud setté est potentiellement invalide.
24/11/2014, 16h26
SylvainPV

Dans quel cas un noeud parent serait invalide ? Avec les exemples sur lesquels je travaille, valider un noeud parent revient à valider le type de ses propriétés, autrement dit ses noeuds enfants. Par exemple, le champ adresse.work est valide seulement s'il contient une propriété city de type String. Donc ces deux fonctionnalités ne viennent pas interférer a priori. Après je peux enlever le null-safe mais étant donné que c'était mon besoin initial... :)
25/11/2014, 00h23
Invité

Citation:

valider un noeud parent revient à valider le type de ses propriétés, autrement dit ses noeuds enfants

tu n'avais pas la validation au début, du coup on pouvait avoir un truc du genre

Code:

address.[[null]].city = 'somestring'

ou [[null]] est la valeur de work.

effectivement, si tu mets une validation sur tout l'arbre alors on est assuré que le set laisse le résultat dans un état valide. (l'impression d'enfoncer une porte ouverte :mouarf:)

Citation:

Après je peux enlever le null-safe mais étant donné que c'était mon besoin initial..

je dis pas de l'enlever, je dirais plutot de les découpler du genre qu'on puisse utiliser une validation sans avoir besoin d'un null safe.
De toute façon, c'est un peu dommage, à chaque set, de faire une validation, et on devrait (enfin je préfère du moins) avoir controle de quand je fais ma validation.
En ce sens, je m'amuse pas à redéfinir 'set' mais appel explicitement la validation.

Le contraire est pas trop gênant vu que syntaxiquement ca change pas grand chose mais pour l'utilisateur qui fait $$$ comme moi, et qui veut utiliser null safe mais pas la validation parce qu'il aime pas comment elle est définie, ben c'est mieux si il peut utiliser null safe sans avoir l'autre composant.

après rien n'empêche de proposer un interfacage entre null safe et validation
un truc genre

Code:

model = defineModel({}, Validation)

où bien,

Code:

model = validateModel({}, NullSafe)
25/11/2014, 10h21
SylvainPV

Je pense que tu n'as pas compris le fonctionnement mis en place. Je ne valide pas les types sur tout l'arbre, je valide uniquement les feuilles. C'est pour ça que je ne vois pas comment un noeud parent pourrait être "invalide", puisqu'il n'y a pas de validation sur ces noeuds. Je pars du principe que lorsque des objets avec des propriétés typées sont utilisées dans le modèle, alors ces objets ont uniquement un rôle de namespace. On pourrait avoir address.work = ["machin","truc"], du moment que c'est un objet sur lequel on peut mettre nos propriétés typées. Ça serait complètement tordu, mais ça respecterait le modèle. Si tu veux empêcher ça, alors il faut typer address.work avec un modèle Address comme l'avait proposé lysandro.

Le null-safe correspond à une seule ligne dans le code :

Code:

var wrapper = obj instanceof Object ? obj : Object.create(null);

Si tu n'en veux pas, retire-la :) Je ne suis pas en train d'essayer de vous vendre un produit, je partage du code et chacun est libre d'expérimenter dessus et de l'adapter à sa façon.
25/11/2014, 10h42
Invité

Citation:

Je pars du principe que lorsque des objets avec des propriétés typées sont utilisées dans le modèle, alors ces objets ont uniquement un rôle de namespace.

oook, au temps pour moi

Citation:

Je ne suis pas en train d'essayer de vous vendre un produit, je partage du code et chacun est libre d'expérimenter dessus et de l'adapter à sa façon.

c'est pas une question de vendre, c'est juste que tu mets un effort dessus, et que ce que tu fais pourrais être utile à d'autre, du coup c'est un peu dommage que ce que tu fais ait un périmètre réduit parce que trop spécifique.
Mais de toute façon, oui, chacun est libre, il n'y a pas de license ;)

J'ai pas tout suivi, mais le problème de base m'a fait penser à cette lib :)

Au lieu de :

Code:

1
2
3
4
var myURL;
if (app && app.config && app.config.environment && app.config.environment.buildURL) {
    myURL = app.config.environment.buildURL('dev');
}

La lib propose :

Code:

1
2
3
4
var myURL;
if (Bro(app).doYouEven('config.environment.buildURL')) {
    myURL = app.config.environment.buildURL('dev');
}

Et pour la gestion d'exception, c'est énorme :

Code:

1
2
3
4
5
Bro(object)
    .braceYourself('method.name')
    .hereComeTheErrors(function(e) {
        console.log('error ' + e + ' happened.');
    });

25/11/2014, 13h22
SylvainPV

Oui je me rappelle de cette lib, une bonne blague :) Mais ça souligne un problème de fond, que les autres langages n'ont pas totalement résolu selon moi (je pense à Groovy et son opérateur .?)
25/11/2014, 15h03
Kaamo

J'ai jamais compris l'existence d'un tel opérateur. Pour moi c'est un hack pour contourner la levée des NPE (NullPointerException)
25/11/2014, 15h44
Invité
en coffee ca s'écrit

Code:

app?.config?.environment?.buildURL

c'est pas tellement en hack lorsque tu considères que tu as des options (c'est plus du sucre syntaxique)
Code:

1 2 3 4 function serve(options){ sugar = options?.withSugar || 'no' doubleDose = options?.withSugar?.quantity || 1 }
25/11/2014, 17h01
SylvainPV

Oui CoffeeScript a repris la syntaxe de Groovy. Je partage le scepticisme de Kaamo: si on a besoin d'introduire un nouvel opérateur, alors c'est plutôt la levée d'exception qui serait à remettre en cause. Avec cette approche, il y a deux extrêmes qui apparaissent: ceux qui remplacent partout le "." par un "?." , et ceux qui utilisent try/catch pour prévenir ce type d'erreurs. D'après moi, ça aurait plus de sens que undefined soit un objet dont toutes les propriétés valent undefined. Enfin, on ne va pas réinventer un langage ici.

Ça m'a donné une nouvelle idée de feature pour mes modèles, les paramètres par défaut. Je vais réfléchir à une syntaxe qui permettrait ça.
11/01/2015, 18h52
SylvainPV

Hello,

J'ai continué à travailler sur ces expérimentations pour produire une bibliothèque grand public.
Après un peu moins de deux mois de taf, voilà enfin le résultat : http://syllab.fr/projets/web/ObjectModel/

Tous les problèmes précédemment évoqués ont été résolus, et plusieurs fonctionnalités ont été rajoutées.
N'hésitez pas à la tester et à me dire ce que vous en pensez ;)
12/01/2015, 09h54
Kaamo

:applo: super clair, et mention spéciale pour le site très clean et bien documenté.
Mes remarques :
- pourquoi avoir attaché Model à Object ? Je pense aux possibles risques de collisions plus tard. (même si les risques sont infimes.)
- penses-tu publier cette lib sur bower / npm ?
- remarque sur la forme : on ne dirait pas plutôt "Which browsers are supported ?" plutôt que "What" ?

C'est vraiment intéressant pour ceux, comme moi, qui se passent d'un langage comme Coffee/TypeScript etc pour générer le JS. Je compte bien l'utiliser dans mes futurs projets :D

edit : ok j'ai ma réponse à la remarque 1 ... pour l'héritage Function.Model
12/01/2015, 11h43
SylvainPV

Pour ta 1ère remarque, j'y ai réfléchi pas mal et je pense que rajouter des propriétés à Object, Function et Array présente un risque de collision suffisamment minime pour être négligé. Il n'existe aucune propriété commençant par une majuscule dans ces objets et rien ne présage que ça puisse changer. Et je trouve ça moins risqué que d'ajouter des variables globales. Au pire si ça dérange vraiment certains, ça peut être très simplement modifié dans le code et je compte de toute manière proposer une version modulaire UMD par la suite.

Pour bower/npm, pourquoi pas si la lib a du succès.

Si tu vois d'autres fautes d'anglais, n'hésitez pas à me les envoyer par MP. Il doit y en avoir un paquet :aie:
05/02/2015, 13h35
danielhagnoul

Pour la gestion de types, tu auras un jour de la concurrence : Google SoundScript: faster OOP for JavaScript
05/02/2015, 14h03
SylvainPV

Dart, AtScript et maintenant SoundScript. Un seul langage ne suffit pas à Google !

Comme concurrents pour du JavaScript type-safe, je pense surtout à Flow et bien évidemment TypeScript.
05/02/2015, 14h45
Kaamo

Ces concurrents font du type checking au moment de la compilation.
Toi c'est au runtime, perso je préfère et ta syntaxe est beaucoup plus JavaScript friendly. J'ai l'impression de + maîtriser ce que je fais.

J'ai vraiment du mal avec ces nouveaux langages qui transpilent en JS
05/02/2015, 16h12
SylvainPV

Tu vas être content, pour la prochaine version j'ai changé l'API en Model.Object au lieu de Object.Model. Ça fait un namespace global, mais j'ai prévu une version UMD pour ceux que ça dérange.
05/02/2015, 16h30
yahiko

Je viens de découvrir ta lib SylvainPV. Pas mal 8-)

Il ne manque plus qu'un linter pour faire de la validation statique et tu pourras concurrencer Google, Facebook et Microsoft ;)

Voir 40 message(s) de cette discussion en une page