On Mon, Dec 17, 2012 at 08:33:47AM -0800, Alan Alpert wrote: > On Sun, Dec 16, 2012 at 5:12 PM, André Pönitz > <[email protected]> wrote: > > On Sun, Dec 16, 2012 at 03:42:59PM -0800, Alan Alpert wrote: > >> On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens > >> <[email protected]> wrote: > >> >> If you create the actions in C++, you'd still have to repeat > >> >> each and every one in QML, unless we provide a way to iterate > >> >> over the ones that should be in a menu, or a toolbar. > >> > > >> > How about having ToolBar.addAction() for convenience? It is > >> > exactly what we do for widgets. > >> > >> Widgets is a toolkit for an imperative language. Looping over > >> lists and adding things individually is acceptable there. In a > >> declarative language it is really not the right way to go. > > > > You make that sound like there was a conceptual difference between > > .ui plus C++ on one side, and some json-ish structure plus JS on > > the other side. > > The conceptual differences are: 1) Bindings. Strict json + JS would > be a lot more similar to .ui plus C++ because it doesn't have > bindings. 2) User approach. .ui files were never meant to be edited > by hand. .qml files are always meant to be edited by hand (even > when the visual designer was around, that was more an aid than the > primary method of editing QML).
I was aiming at the seemingly implied conceptual difference in the style - imperative vs declarative - between the approaches, which does not really exist. My statement was probably missing a "regarding 'declarativeness'" or whatever makes that a proper English sentence and the context crystal clear. Anyway, I don't think 2) is a valid reason, no matter whether the "regarding 'declarativeness'" is there or not. Translating .ui into "json-ish" and back can be a purely mechanical and lossless task doable without introducing imperative blobs. "Making the .ui format more accessible to manual editing" would be rather straightforward, if that was a goal. Somewhat similar for 1). I haven't given it a shot, but I find it hard to believe that a "binding evaluation machine" within_ the existing framework should be ugly, let alone impossible. We are approaching a time where we can use C++ lambdas, and lacking them, we by now have some practice to convert source markup into real code. Putting some binding code into normal string literal and running them through a simple(!) interpreter at runtime should not be completely off the mark either. Lots of possible approaches. In any case, I fail to see the intrisic complexity of the problem that justifies the effort we see spent on the "language side" of the issue, both for the implementors, and for the users. But back to the original issue, within the intended context: The point is that with the existence of arbitrary imperative blobs with arbitrary side effects and full access to global data a language's claim to be "declarative" is hard to defend - both in theory, and in practice. I personally find the practical implications for the tooling side of things particularly irritating as all benefits of a pure declarative approach are rendered void. Moreover, the chosen implementation as "json-ish"-plus-JS hybrid exposes us to all the downsides of a domain specific language. No standard to tell what's right and wrong, no existing tooling to re-use, no shoulders of giants to stand on etc. At the end of the day I see a lot of pain for no gain. Why are we doing that? Andre' _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
