From koffice-devel Sun Feb 18 19:51:01 2007 From: Sebastian Sauer Date: Sun, 18 Feb 2007 19:51:01 +0000 To: koffice-devel Subject: Re: koffice/libs/kross/ruby Message-Id: <200702182051.01368.mail () dipe ! org> X-MARC-Message: https://marc.info/?l=koffice-devel&m=117182843917765 Cyrille Berger wrote: > In OO programming it's better to have: > class MyScript > def initMe(*args): pass > def getName(): return "ThisIsMe" > def doSomethingOnRequest(*args): return "Done" > end > WhatEverCoolRegistry.register(MyScript.new) > > Defining functions to do this is C-like programming ;) Hopefully unlike C > you don't have to fill a structure with pointers to your function. > y, I agree there. But on the other hand we could also assume that the file itself is a class too (in python it's handled as module) and those functions are just member-variables of them ;) >> and then load the script and call the functions from within C++ code on >> demand (n scripts/plugins with the same functionnames loaded the same >> time). The current callFunction implementation is just very bad >> performance-wise anyway. > what's wrong ? except the parsing/compilation of the file for every > callFunction... callFunction takes a QVariantList for it's arguments what means we are dealing with a list what sucks if you just call something like myfunc(int,int). The long time goal could be to just let Script-classes build slots for each function and to allow execution of the slots via QMetaObject::invokeMethod. This saves at least to create and deal with a list on each call. >> So, propably there is a better way to "emulate" >> such behavior and get such single script functions executed from within >> C++ (maybe e.g. with a signals and slot hack?) ?! > Why that would be better ? Cause signals and slots do know there signature and therefore we are able to prevent dealing with a common QVariantList rather then just it's exact arguments at e.g. "myfunc(int,int)". But if we would some day replace the generic callFunction which doesn't know anything about it's real argtypes with a QMetaObject::invokeMethod like method (or like the proxy.h functionality from 1.6), then we are able to deal with the real argtypes too. -- Sebastian Sauer aka dipesh[sebsauer] http://www.dipe.org/public_key.asc Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221 Coder in http://www.koffice.org && http://www.kmldonkey.org _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel