Archief - [PROG] dynamisch methoden aanroepen

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

schop aars

Legacy Member
moet dynamisch methoden kunnen aanroepen.

M.a.w. de methoden, klassen, volgorde van uitvoeren van methoden enzo zouden in een database zitten. Het programma moet dan de methoden in de juiste volgorde uitgevoeren.

heeft iemand dit al eens gedaan? of heeft iemand een idee hoe je dit kan doen?

hoe zou de database en het programm er uit zien?

btw:wat met tussenresultaten? dus als een methode iets returned dat je moet gebruiken in een volgende methode hoe hou je dat dan bij in je database?

Cyberkef

Legacy Member
Moet het in een specifieke taal zijn? Of bedoel je het eerder algemeen?

(Java bvb heeft de klasse ClassLoader)

schop aars

Legacy Member
mja zou in java zijn maar kan ook in andere taal zijn

mijn vraag is eigenlijk eerder hoe zou die database er uit zien die dat doet en hoe zou het programma werken? dus niet zozeer de code (die kan ik zelf ook wel schrijven) maar eerder de werking

Bavo aka Joske

Legacy Member
Wel een heel vreemde vraag hoor. Je zou een workflow model kunnen maken (workflow tabel, command tabel met (taak id, workflow id, java klasse en method) die voor elke actie een Command aanroept (Command pattern), via reflectie eventueel. De resultaten sla je dan maar op in generieke een tabel per taak ofzo (taak id, varchar type, varchar resultaat)

Dit is heel ruw maar een mogelijkheid. De vraag uiteraard is, waarom :)

Workflow past veel beter in een BPM omgeving dan DB.

killgore

Legacy Member
wat is exact je bedoeling, want zoals jij het beschrijft wil je gewoon een interpreter maken :/

schop aars

Legacy Member
het is een applicatie die bepaalde invoer krijgt via een formulier
die informatie moet dan via een API naar een systeem gestuurd worden.

de bedoeling is dus dat als een nieuw systeem toegevoegd word je gewoon de methoden en hun parameters enzo in een database komen.
Op die manier zou je dus een nieuw systeem kunnen aanspreken zonder de programmacode te wijzigen.

killgore

Legacy Member
het probleem is dat dit wel degelijk taalafhankelijk is.
Als je dit in C++ wilt doen bv. zal je al functiepointers (adressen) moeten opslaan, en dan zit je met het immense probleem dat je je programma nooit mag hercompileren :p. Dus ik zou zeggen dat het enkel in interpreted languages of via reflection mogelijk is.

In dat geval ben je in principe genoeg met het opslaan van de namen van de functies en de parameters (eventueel de types in typesafe languages).
Zeer volledig zou afaik zoiets zijn:


tabel functies (naam, id)
tabel body (functieid,parameterid, volgorde)
tabel parameters (id, type)

gelinkt als volgt:
functies (1)<->(0..n)body(1)<->(1)parameters

Dit is natuurlijk zwaar overdreven gesplitst om persistentie te verzekeren, praktisch zal je parametertype wrsch wel in body steken. merk op dat je per overload een nieuwe functie aanmaakt (functienaam is dus niet uniek ofzo). Eventueel kan je natuurlijk extra zaken als namespaces/packages gaan toevoegen, maar dat zijn details ofcourse.

Dan deze tabellen:
systeem (id, naam, extra_info)
implementatie (systeemid, functieid, volgorde)
parameter(id,value,implementatieid,boolean functionresult, volgorde)

gelinkt:
systeem(1)<->(1..n)implementatie(1)<->(1)functies
implementatie(1)<->(0..n)parameter

analoog aan voorgaande, je kan natuurlijk weer enkele tabellen schrappen ten koste van persistentierisico en denormalisatie :).
ivm parameter: value zit hierin, maar dit kan natuurlijk ook een berekend resultaat zijn, dan steek je in value bv. het nummer van de functieaanroep ofzo, dat is zelf wat zoeken.

let wel op dat in implementatie en body de parameter volgorde essentieel is. Je moet dus zorgen dat deze uniek is (logische manier is bv. in body de key (functieid,volgorde) primary te maken).

Dat is dus hoe ik het algemeen zou doen voor interpreted zaken.

Reden dat ik het functies gedeelte quasi volledig splits en zo sterk normaliseerde is omdat dit een vrij cruciaal gedeelte is. Je wilt dat je parameters correct zijn en je wilt dat er niet per ongeluk system calls in je db steken (stel je voor dat mensen in een php omgeving toegang hebben tot exec).

Hoe je het specifiek afhandelt is zéér taalafhankelijk, maar in principe zal je al beschikken over een array/vector/lijst/collectiontypenaarkeuze die in goede volgorde je uit te voeren statements + parameters beschikt. In pakweg php komt het er dan nog maar op aan eval aan te roepen. Natuurlijk komen er extra's bij zoals kijken of parameters kloppen, zorgen dat resultaten worden bijgehouden en aan een id (volgorde) worden gelinkt indien ze weer nodig zijn, maar dit hangt zeer sterk af van hoe je systeem werkt :). In php parse je dat gewoon (bv. $result[$volgorde] = ...), in java zal het iets anders zijn.

edit: dit is wat ik interpreteerde dus, kan zijn dat ik wat naast jouw idee zit, maar ik hoop dat je het al een of ander beeld geeft.

schop aars

Legacy Member
hmm dit is inderdaad wat ik zocht.
dat van reflection had ik ook al gevonden maar nog geen deftig databasemodel.

thx
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan