[Qt-qml] Pragmas for QML

[warwick.allison at nokia.com]

I advise caution on this. Think about QML files relative to, say, a C/C++ program. Typically, the unit of modularity in a C/C++ program is the *file*, with pretty strict engineering practices around it (and only a little bit from the language itself).

Now consider you QML files. Really, they are so small as to be more comparable to a single C/C++ function or method. Therefore, you should perhaps think of the unit of modularity for QML to be a *directory* of files, and this is a concept directly supported by QML's qmldir and import mechanism.

If you find you're abusing scoping, it probably means you have too many files in a single module, just as a huge single-file C/C++ classes becomes unmaintainable.

Break it up into smaller reusable units - in their own directories - and use the import interfaces accordingly.

--
Warwick

> -----Original Message-----
> From: qt-qml-bounces at trolltech.com [mailto:qt-qml-
> bounces at trolltech.com] On Behalf Of ext Girish Ramakrishnan
> Sent: Tuesday, November 30, 2010 4:46 PM
> To: qt-qml at trolltech.com
> Subject: [Qt-qml] Pragmas for QML
> 
> Hi,
> Hope you are all having fun reading existing QML ;-) What I am finding
> is creating QML is an exceeding simple task compared to reading
> other's QML. The main culprit that inhibits my reading is the
> 'Component instance hierarchy' feature in
> http://doc.qt.nokia.com/4.7-snapshot/qdeclarativescope.html. The code
> which I am reading accesses components and ids all over the place. For
> example, if we had a Component heirarchy A that contains B that inturn
> contains C - C would access ids of A. B would set state (yes, _state_)
> of something in A. C would react on states of A etc. When used this
> way, ids have to be 'unique' and I think this pattern in most cases
> results in unreadable code (as shown in the example in the
> documentation too).
> 
> Authors seems to think of all these ids as a global pool of objects
> that can be accessed from anywhere and think that this is declarative
> programming e.g. C.state = A.something. Yes, it's declarative but it
> should be done the other way around, in A's code, no?
> 
> So, am I correct in thinking that in general, a component should
> _never_ really access anything else other than ids of it's own
> regardless of how un-reusable and specialized it is? Each qml
> component as much as possible should expose stuff as properties and
> bindings should be done in the _parent_ component. I do understand
> that there are cases that require child components to access parent
> stuff.
> 
> So, is it a sane suggestion/feature request to add a 'pragma
> strictScope' which I can add to the top of a QML file to disable this
> feature? It would make reading QML infinitely good for me. Reminds me
> of VB - the first thing in do is add 'Option Explicit' :-) I would do
> the same in qml. Let me know if I am thinking very 'imperatively' :-)
> 
> On the topic of pragmas, I would also like to have a 'pragma
> noSyntacticSugar'. QML has shortcuts which make it very hard for
> beginners to understand why things don't work in QML. For example,
> ListView {
>     delegate: Text { text: model.text }
> }
> versus
> Text { id: textDelegate; text: model.text }
> ListView {
>     delegate: textDelegate;
> }
> 
> Oops, latter doesn't work. So, it would be nice to force people to
> write Component { } so they _understand_ what's happening. Same goes
> for default properties (I am looking the 'children' property).
> 
> Girish
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-qml