[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice/libs/kross/ruby
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-02-18 19:51:01
Message-ID: 200702182051.01368.mail () dipe ! org
[Download RAW message or body]

Cyrille Berger wrote:

> <personal opinion>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.
>  </personal opinion>

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
[prev in list] [next in list] [prev in thread] [next in thread]