Salut,
Je viens de découvrir le projet, j'avoue ne pas voir sa finalité, à quoi il va servir ?
Plus d'explications seront les bienvenus.:roll:
Version imprimable
Salut,
Je viens de découvrir le projet, j'avoue ne pas voir sa finalité, à quoi il va servir ?
Plus d'explications seront les bienvenus.:roll:
En fait il s'agit d'un compilateur/interpréteur, mais orienté plug-in, donc développé dans le sens ou du code compilé sera intégré à une application existante.
Si tu as une application Delphi qui voudrait proposer la création de plugs-in à ses utilisateurs, Sepi est fait pour toi (enfin... quand il sera opérationnel :lol:).
Mais comme je l'ai déjà dit, Sepi a une conception de plug-in beaucoup plus poussée que l'idée qu'on s'en fait habituellement. Du code Sepi pourra être exécuté par l'application hôte, en créant des objets et en exécutant leurs méthodes, ou en appelant des routines etc.
Mais ce qui est également intéressant, c'est que du code Sepi pourra faire appel à des routines codées dans l'application, en Delphi. Il pourra créer des objets natifs, et appeler ses méthodes, modifier ses propriétés, etc.
Pour pousser, si tu crées une classe Sepi qui surcharge une méthode virtuelle Delphi ; que tu crées un objet de cette classe Sepi, puis que l'assignes à une variable Delphi de la classe Sepi ; et que tu appelles la méthode virtuelle, c'est effectivement la méthode surchargée en Sepi qui sera appelée.
Maintenant tu as les possibilités qu'offre Sepi. Pour savoir à quoi sert Sepi, je n'ai pas encore trouvé mieux que de donner mon application en vue : FunLabyrinthe.
Il s'agit d'un jeu de labyrinthe dans lequel il est possible, lorsqu'on crée ses propres labyrinthes, de créer ses propres cases. Les effets de ces cases sont écrits dans un langage extrêmement basique : une instruction ressemble à ceci :
Cette instruction a pour effet de remplacer la case en coordonnées (3, 3, 1) par de l'herbe (dont le code 0).Code:Remplacer Case 3 3 1 0
Mon but est d'améliorer les possibilités de création des cases en permettant de créer des nouvelles classes pour ces cases, descendantes des classes existantes (herbe, mur, eau, ou clef par exemple... il y en beaucoup), afin d'étendre leur comportement.
En effet, la syntaxe pauvre de ce langage et le paradigme actuel de FunLabyrinthe limitent fortement ses possibilités. Il n'est en effet pas possible d'hériter les comportements d'un case à partir d'une autre existante.
Est-ce que cela te paraît plus convainquant ? Ou c'est toujours très obscur :?
Parfois, le côté obscur est plus fascinant que le reste...Citation:
Envoyé par SJRD
sérieusement, on pourait pas faire la même chose avec Delphi ?Citation:
Envoyé par SJRD
(je devine ta réaction, mais fait comme si t'a rien vu, rien entendu...sinon je craint un coup de boule !)
T'en fais pas, je m'attendais à la question ;)Citation:
Envoyé par Bejaia-In
En fait, oui, on peut très bien faire la même chose en Delphi, avec des packages chargés dynamiquement, etc. Mais on ça veut dire les développeurs qui disposent d'une license Delphi.
Or mon but est d'ouvrir cela aux utilisateurs des programmes, qui ne sont en général ni développeurs ni détenteurs de Delphi.
Donc il faut pouvoir offrir différents langages : des plus avancés orientés objet et tout et tout pour créer des plug-in (et des labyrinthes, dans mon cas) de la mort qui tue ; jusqu'aux plus simples que n'importe quel utilisateur lambda peut comprendre.
Et tous ces langages doivent être compilés dans un même schéma exploitable facilement ;)
C'est pointu comme projet, je ne sais pas si j'ai les compétences requises mais si je peux aider je le ferais.
bonne chance.;)
:merci:Citation:
Envoyé par Bejaia-In