 |
| ajout d'une fonction distante dans un objet | |
| johnatemps | 5-Nov-2007/15:08:38+1:00 |
| Bonjour, Je voulais faire quelque chose de tout bête, et je bloque. J'ai un script dans un fichier unique, construit de cette manière :
mon-context: context [
ma-fonction: does [... beaucoup de lignes]
mon-objet: make object! [... beaucoup de lignes]
load: does [...]
]
;utilisation
mon-contexte/load
Je souhaitais découper un peu ce gros fichier, mais garder mon contexte, pour éviter de travailler directement dans le contexte global. J'ai trouvé pour un objet, je fais mon-objet: do load %mon-fichier avec mon-fichier contenant make object! [plein de lignes] Je souhaiterais faire quelque chose de similaire avec une fonction, mais... je trouve pas. Il y a une histoire de gestion de contexte, c'est certain, car la fonction revoit une erreur en ne trouvant pas un mot qui est dans mon-contexte... | |
| guest2 | 5-Nov-2007/18:12:17+1:00 |
| Salut, Bon là tu cherches un peu les emmerdes faut dire. y'a une méthode chiante qui consiste à rebinder le contenu des tes fichiers (loadés) dans ton objet. En simple, y'a la soluce du compose.
mon-context: context compose/deep [
ma-fonction: does [(load %ma-fonction)]
mon-objet: make object! [(load %mon-objet)]
load: does [(load %load)]
]
Mais gaffe, dans les fichiers tu dois avoir du code non encapsulé dans un objet ou un bloc. | |
| johnatemps | 5-Nov-2007/18:46:41+1:00 |
| Le bon vieux compose/deep , j'y avais pas pensé. Disons que j'avais pas l'impression de chercher les emmerdes, plutôt d'utiliser deux règles de bonne conduite : - découper en fichier, pour éviter le syndrome du script de plus de 1000 lignes, et donc pour mieux organiser les choses. - mettre toute l'appli dans un contexte, pour bien délimiter les choses aussi. Résultat, si l'on veut une solution simple, on ne doit appliquer qu'une de ces règles ? Je trouve cela curieux d'être le premier à vouloir faire cela. Je m'en vais garder mon gros script. Car pour le moment, ma démarche est loin d'apporter la limpidité attendue. | |
| guest2 | 5-Nov-2007/18:58:01+1:00 |
| C'est à dire qu'en général, moi je load un objet complet à partir d'un seul fichier (pour éviter ton problème). Si ton objet et mega über, il faut penser à le réécrire en plus concis, en factorisant ce qui peut l'être. (je sais c'est plus facile à dire qu'à faire) | |
| guest2 | 5-Nov-2007/19:01:38+1:00 |
| Ah j'oubliais: Le préprocesseur REBOL a justement été créé pour régler ce problème. la fameuse commande #include qui permet d'insérer plusieurs scripts dans un seul source. | |
| guest2 | 5-Nov-2007/19:07:50+1:00 |
| http://www.fm.tul.cz/~ladislav/rebol/include.html | |
| johnatemps | 5-Nov-2007/19:08:48+1:00 |
| Oui, #include, je faisais ainsi habituellement, un tas d'include. Et là, j'essayais une autre option, car je ne souhaitais pas encaper tout. Je suis en train de regarder du coté de l'imbrication d'objets. En effet, j'ai tout mis dans un gros contexte... Eh bien, je vais plutôt essayer avec une série d'objets. Genre, au lieu d'avoir : mon-appli: context [ objet1 objet2 code de l'appli ] aller vers objet1 objet2 mon-appli: context [ code de l'appli ] Le problème, avec Rebol, c'est qu'on peut coder longtemps, avant d'avoir besoin d'une archi impeccable. | |
| guest2 | 5-Nov-2007/19:24:41+1:00 |
| Oui je le disais encore recemment dans un autre post. Rebol souffre des même limites que n'importe quel autre language. Quand ça devient gros, ça devient difficilement maintenable si on a pas conçu une bonne architecture en amont. Les 4 règles de la séparation du code que je m'emploie à respecter: séparation du code de gestion des données, séparation du code gérant l'ihm, séparation du code métier, séparation du code technique. | |
| johnatemps | 5-Nov-2007/22:37:30+1:00 |
| C'est presque du MVC ça (model view controler) Autre règle, tant qu'on est dans le sujet: se donner du temps pour réécrire le code, sans chercher autre chose que la lisibilité. Pas d'ajout de fonctionnalité, mais pas de régression non plus. | |
| ZeBrain | 6-Nov-2007/23:23:38+1:00 |
C'est beau de rêver  Y'a pas beaucoup de développeurs pro qui ont le temps de faire ça. Pourtant les meilleurs logiciels ont pris le temps qu'il faut pour mûrir. | |
| guest2 | 6-Nov-2007/23:38:50+1:00 |
| Question d'expérience, quand je sais que je vais faire un gros projet, je prévois d'abord la façon dont je vais architecturer les différents modules en fonction des critères que j'ai indiqués. C'est plus facile à faire avant, que après. Et surtout on gagne du temps pour la suite. Zebrain ce que tu dis ne m'étonne pas, je vois trop de développeurs (la presque totalité en fait) squizer la phase d'étude architecturale du projet sous prétexte qu'on a pas le temps, et evidemment ça se paye après avec des usines à gaz immaintenables. | |
| ZeBrain | 7-Nov-2007/11:54:48+1:00 |
| J'ai déjà maintenu ce genre de "blob" sans architecture et sans lisibilité et c'est tout de suite 2 heures pour modifier un détail ridicule. | |
| johnatemps | 14-Nov-2007/10:26:50+1:00 |
| Disons que parfois, l'envie de coder un truc, peut démanger... surtout avec rebol, où il suffit parfois de 3 lignes (remplies) de console, pour vérifier qqch. Mais faut rester dans une idée de test rapide, et repasser par la phase d'archi avant de monter en complexité... | |
| shadwolf | 1-Dec-2007/5:34:39+1:00 |
| ZEbrain ouai et certain logiciels sont toujours pas mûrs --> 15 eme version de MS word non franchement y a de l'abus lol | |
| shadwolf | 1-Dec-2007/9:48:12+1:00 |
| hum .... peu de fichiers avec bcp code ou bcp de fichiers avec peu de codes tel est le cruel dilem du développeur... A ma connaissance ya absolument aucun langage qui reponds convenablement a cette problèmatique. J'aurait tendance a dire REBOL apporte depart sa syntaxe allégée une ébauche de réponse mais encore faut il conserver dans sa programation l'aspect light ce que est pas tjrs facil surtout qunad on fait du VID. VID a tendance quand on sort des sentier battus a être puissement verbeux et ennuyeu. | |
| shadwolf | 1-Dec-2007/9:51:29+1:00 |
| d'ailleurs en lisant quelque commentaires fait par guest2 sur R3 et le VID3 (gob feel truc_muche) ca me semble pas etre parti pour s'amméliorer. Vais je enfin pouvoir finir mon moteur de rendu SVG ? Ca fait quand meme 2 ans que j'attends que 2 povre bugs soient corrigés ... | |
| shadwolf | 1-Dec-2007/9:52:08+1:00 |
| d'ailleurs en lisant quelque commentaires fait par guest2 sur R3 et le VID3 (gob feel truc_muche) ca me semble pas etre parti pour s'amméliorer. Vais je enfin pouvoir finir mon moteur de rendu SVG ? Ca fait quand meme 2 ans que j'attends que 2 povre bugs soient corrigés ... | |
| shadwolf | 1-Dec-2007/10:28:49+1:00 |
| je rattrappe petit à mon retard de lecture donc pour R3 j'ia bien aimé le comparatif No more face hacking: view layout [ button "Test" with [ ...lots of face hacking code...] button "Quit" with [... more face hacking code...] ] But now: view [ button "Test" quit-button ] Ca fait plaisir je suis pas le seul a trouver que VID a tendance à généré bcp de trop de code inutilement. Fort de ce constat espérons que VID3 serra aussi light quand il sagit d'ecrire ces propres faces. | |
| guest2 | 3-Dec-2007/15:13:32+1:00 |
| Yo Shad ! C'est pas pour faire le rabat-joie mais en VID2 on peut aussi faire un View [ button "test" quit-button ] En surchargeant les styles en amont. D'ailleurs je crois que VID3 ne propose pas autre chose que d'encourager le développeur à faire des styles plutot que de hacker ses layouts (mais si on veut programmer goret, on peut toujours, ouf!). En même temps, je dis ça et je dis rien, car VID3 pour l'instant ça n'existe pas. La seule chose que j'ai vu dans Devbase c'est une tentative de simuler des faces de type VID2 avec la nouvelle architecture de gobs. Et je dois dire que le code est assez assez laid. | |
|
Login required to Post. | |