[Kde-bindings] SMOKEv4 proposals

[Dimitar Dobrev]

Hi,

I have a few notes:

(4) I can't say I completely understand this feature but if this singleton is the better solution, i.e. it'd gather all these dispersed SmokeClass and etc. types, why should it be optional? Why not make it the only option?

(5) I don't think the difference is that large but as taking the argument names from files performs better after all and it's already done and works, why not simply leave it as is?

(6) How about including that mechanism (either in SMOKE or as an addition to SMOKE) that sends notifications when any Qt object is destroyed, not just SMOKE Qt objects as it is now?

And a last remark concerning all points: I think there should be some kind of a short list how the bindings should be changed to accommodate the new SMOKE.



________________________________
 From: Arno Rehn <arno at arnorehn.de>
To: KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Saturday, September 8, 2012 5:25 PM
Subject: [Kde-bindings] SMOKEv4 proposals
 
Hi,

now that Qt5 beta is released, I'd like propose some BC and/or
functionality breaking changes for SMOKE (hopefully finished in time
for KDE Frameworks 5):

(1) Move dynamic dispatch resolution from SMOKE to the binding libs.
    Reason: Currently, some multiple inheritance + dynamic_cast
    sorcery decides whether the virtual method call should be
    resolved with dynamic dispatch or not. While it works as expected,
    it is horribly slow.
    The bindings normally keep track of whether an object was allocated
    by SMOKE. This information can be used to determine
    whether to use dynamic dispatch or not. I've already implemented
    this in the 'smokev4' branch in smokegen. The default 'classFn
    method id' will call the dynamically dispatched method, 'id + 1'
    will do a direct call.

(2) Get rid of the 'external' boolean field in Smoke::Class. It already
    has 'flags' and Smoke::cf_undefined, which serves the same purpose.
    (already implemented in the 'smokev4' branch).

(3) Get rid of Smoke::classMap. It's a hack to do quick cross-module
    class lookups, but it introduces a big std::map which holds copies
    of all class names, essentially duplicating the information.

(4) Create a new, but entirely optional to use, singleton object which
    manages the loaded smoke modules. It will keep track of all loaded
    modules, contain intelligent algorithms to do cross-module class
    lookups and generally have a higher-level interface than the
    low-level 'Smoke' class. It should only depend on the C++ standard
    library. We already have some parts for this: SmokeClass,
    SmokeMethod, SmokeType, etc.. are currently all copied to every
    bindings project, but are rarely used. For a different project, I've
    already extended their interfaces quite a bit (sorry for the long
    link):

http://quickgit.kde.org/index.php?p=scratch%2Farnorehn%2Fqtcrack.git&a=blob&h=0fb6331e8439dae9aaf21cd4f1899effcf3a1fe5&hb=a7df18898e8008aa33df5e0dc05cecfd558d114a&f=smokeext%2Fsmokeutils.h

(5) Add more meta information to smoke. We've already discussed adding
    method argument names, which sounds like a good idea and shouldn't
    weigh too much with proper string interning.
    We should also consider having only one 'string table' in the smoke
    lib, which could save some more bytes (e.g. many classnames will be
    identical to the constructor names, some argument names are probably
    identical to some method names, etc..).
    It would be greate if we can come up with something that lets us
    add more meta-information later without breaking BC again. Adding
    traditional virtual methods to the 'Smoke' class might not be such
    good idea because it would break C compatibility, but maybe some
    'manual' offset table with pointers to structs/funcs could be used.

Can you think of anything else?

Looking forward to your feedback :-)

-- Arno Rehn
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20120908/79a80541/attachment.html>