[Development] Enumerations in QML

Chris Adams chris.adams at qinetic.com.au
Thu Dec 13 02:06:05 CET 2012


> This entire thread should be revisited after QTBUG-24799 is fixed.
> >
> I disagree here, because
> A) How much we like enums affects the effective priority of
> QTBUG-24799 (it's the main usecase that it blocks)

True.  Although it also affects instanceOf and Qt.createComponent, at the
very least.  But I agree that enums is the main one.

> B) We might find a solution that works around QTBUG-24799 (okay, not
> looking very likely)

Well, any solution that works around not being able to resolve typenames is
going to be a hack (like objectinstance.enumProperty["EnumName"] or
something).  And it doesn't work for the other, non-enum use cases (in
which the typename itself is the only important consideration).

> C) Someone might want to fix this and QTBUG-24799 at the same time.

Sure, this is my point.  If they want enums, they should fix QTBUG-24799.

> Since this is currently necessary, it does mean that anyone who wants
> to see enums properly supported should help out with the v4vm work
> (currently the best way to fix QTBUG-24799).

The v4vm implementation is an orthogonal issue entirely.  Let me put it
this way: this "unresolvable typename" issue existed in 4.x when we used
JSC, and it exists in 5.0 now that we're using V8, and it will exist in 5.1
or 5.2 when we use v4vm.  The problem is an issue with QML's typesystem,
not the JavaScript engine which we use.  Unless you're saying that the v4vm
effort also involves improving the typesystem for performance or other
reasons (which is entirely possible, I haven't looked into it too deeply
yet, unfortunately).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121213/79733b51/attachment.html>

More information about the Development mailing list