[Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Simon Hausmann]

On Wednesday 30. April 2014 06.32.28 Rutledge Shawn wrote:
> On 29 Apr 2014, at 7:51 PM, Alan Alpert wrote:
> >> (3) Document that accessing ids from other .qml files without any
> >> interface (just relying on the fact that they are in the context)
> >> creates hard to maintain QML code.> 
> > Agreed (honestly, it should already be there, I guess
> > https://bugreports.qt-project.org/browse/QTBUG-20453 was never
> > finished...).
> > 
> > Again, we have some rough plans for a ".pragma strict". Which should ban
> > this.
> What exactly do you want to ban and what are the best alternatives? 
> "Without any interface" implies there is a right way to share.
> 
> - attached properties need to be created in C++ and are anyway unintuitive
> - singletons need to be created in c++ and don't restrict the scope

Actually singletons can now also be created in Qml. A pattern we should 
consider promoting.

> - objects can be put in the context in c++

Ah, setContextProperty? Yeah, we could warn against that.

> - a shared JS file could be used but that's not declarative
> - there is no extern keyword; would it make sense to have something
> analogous?  but like singletons everything would be in the same name space
> - combined use of "parent", and the dot operator to drill down to something
> not directly accessible, quickly becomes ugly
> 
> In practice I'm often not sure about the scoping rules, so when something
> that I think should be accessible is not, I'm often not sure if that is a
> bug but just start looking for another way to do it (which sometimes can be
> clumsy).
> 
> https://bugreports.qt-project.org/browse/QTBUG-38591 doesn't seem to have a
> really satisfying solution at first glance…

Perhaps the solution would be to declare up-front the names (and types?) of 
properties we expect the "parent context" to supply?

But otherwise the solution is properties in the root object of your component, 
set by the code that instantiates it (for example via properties supplied to 
createObject or declaratively).


Simon