<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">Hi,<br><br>I have a few notes:<br><br>(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?<br><div><span>(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?<br></span></div><div>(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?</div><div><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">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.<br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Arno Rehn <arno@arnorehn.de><br> <b><span style="font-weight: bold;">To:</span></b> KDE bindings for other programming languages <kde-bindings@kde.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, September 8, 2012 5:25 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> [Kde-bindings] SMOKEv4 proposals<br>
</font> </div> <br>
Hi,<br><br>now that Qt5 beta is released, I'd like propose some BC and/or<br>functionality breaking changes for SMOKE (hopefully finished in time<br>for KDE Frameworks 5):<br><br>(1) Move dynamic dispatch resolution from SMOKE to the binding libs.<br> Reason: Currently, some multiple inheritance + dynamic_cast<br> sorcery decides whether the virtual method call should be<br> resolved with dynamic dispatch or not. While it works as expected,<br> it is horribly slow.<br> The bindings normally keep track of whether an object was allocated<br> by SMOKE. This information can be used to determine<br> whether to use dynamic dispatch or not. I've already implemented<br> this in the 'smokev4' branch in smokegen. The default 'classFn<br> method id' will call the dynamically dispatched method, 'id + 1'<br> will do a direct
call.<br><br>(2) Get rid of the 'external' boolean field in Smoke::Class. It already<br> has 'flags' and Smoke::cf_undefined, which serves the same purpose.<br> (already implemented in the 'smokev4' branch).<br><br>(3) Get rid of Smoke::classMap. It's a hack to do quick cross-module<br> class lookups, but it introduces a big std::map which holds copies<br> of all class names, essentially duplicating the information.<br><br>(4) Create a new, but entirely optional to use, singleton object which<br> manages the loaded smoke modules. It will keep track of all loaded<br> modules, contain intelligent algorithms to do cross-module class<br> lookups and generally have a higher-level interface than the<br> low-level 'Smoke' class. It should only depend on the C++ standard<br> library. We already have some parts for this: SmokeClass,<br>
SmokeMethod, SmokeType, etc.. are currently all copied to every<br> bindings project, but are rarely used. For a different project, I've<br> already extended their interfaces quite a bit (sorry for the long<br> link):<br><br>http://quickgit.kde.org/index.php?p=scratch%2Farnorehn%2Fqtcrack.git&a=blob&h=0fb6331e8439dae9aaf21cd4f1899effcf3a1fe5&hb=a7df18898e8008aa33df5e0dc05cecfd558d114a&f=smokeext%2Fsmokeutils.h<br><br>(5) Add more meta information to smoke. We've already discussed adding<br> method argument names, which sounds like a good idea and shouldn't<br> weigh too much with proper string interning.<br> We should also consider having only one 'string table' in the smoke<br> lib, which could save some more bytes (e.g. many classnames will be<br> identical to the constructor names, some argument names are probably<br>
identical to some method names, etc..).<br> It would be greate if we can come up with something that lets us<br> add more meta-information later without breaking BC again. Adding<br> traditional virtual methods to the 'Smoke' class might not be such<br> good idea because it would break C compatibility, but maybe some<br> 'manual' offset table with pointers to structs/funcs could be used.<br><br>Can you think of anything else?<br><br>Looking forward to your feedback :-)<br><br>-- Arno Rehn<br>_______________________________________________<br>Kde-bindings mailing list<br><a ymailto="mailto:Kde-bindings@kde.org" href="mailto:Kde-bindings@kde.org">Kde-bindings@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kde-bindings" target="_blank">https://mail.kde.org/mailman/listinfo/kde-bindings</a><br><br><br> </div> </div> </div></body></html>