Bill Baxter Wrote: > In Qt the binding is more dynamic. You can call a slot in Qt even if > all you have is its name in a run-time string. > Qt also uses a similar mechanism to provide runtime dynamic > properties. For anything derived from QObject you can ask if it has a > "color" property (again using a string), for instance. Given enough > reflection capabilities, D could potentially turn compile time info > into similar run-time queryable strings, so I'm guessing that's why > they said they might not need MOC if D's reflection proves sufficient. > Qt may also be able to add a
This is exactly correct. Even D2 currently lacks the introspection capabilities provided by moc. In addition to providing the code for signals/solts moc also provides for things like getting a list of enums in a class, converting enum values to and from string (technically moc doesn't do this conversion, it just makes it possible), a string list of object properties and their types, you can even add new signals and slots dynamically at run time (which may not even be members of the class that you are declaring them to be a slot of). Qt's signal/slot implementation is also thread safe (connecting a signal from one thread to a slot in another I mean), and provides several options for how a slot actually gets called by a signal (directly, via the event loop, etc). This level of "dynamic-ness" is what makes bindings to Qt possible in the first place. People often forget, though, that Qt actually has 2 programs which typically run before compilation, moc and uic. uic is responsible for converting the XML files generated by Qt Designer into C++. Even if you do away with running moc first, you still need to run uic. I would love if we could not need moc, but unless D2's introspection improves a lot before QtD is ready it will probably be a neccesity and there is no good way around using uic. Sure you can load and process the xml files at runtime, but there is of course a real performance cost to that compared with compiling in standard code. > But really signals and slots is just an interesting implementation > detail about Qt. What makes it great to me is just the completeness > of it and the amount of thought which has gone into making a clean, > clear and consistent API. The docs are also great. I totally agree, having a single, consistent framework for everything from TCP connections to rendering advanced 2d graphics scenes to embeding OpenGL and shared memory handling (plus a lot more of course) makes it hands down one of the best toolkits available. Not only is its API clean, clear, and consistent, its internal implementation generally shares these qualities. > It's kinda like that all over. Tons of small things everywhere in Qt > that just make you go, "Oh that's really nice". You can write real > applications just fine using either wx or Qt, but very seldom do I > have those "oh wow" moments using wx. I have been using Qt for years now, and I still have those "oh wow" moments. P.S. You may have guessed this already, but I'm one of the developers working on QtD ;-) --- Katrina
