[Development] Enumerations in QML

[Alan Alpert]

On Thu, Dec 13, 2012 at 2:09 AM, Erik Verbruggen <erik.verbruggen at me.com> wrote:
> Replying to myself after a bit of pondering...
>
> On Dec 12, 2012, at 10:45, Verbruggen Erik <Erik.Verbruggen at digia.com> wrote:
>
>> The problem with enums is that we couldn't make them fast. They will always be a lot slower than normal string literals. That is mostly because we could not avoid the name lookup. Think about,
>>
>>   Text {
>>           alignment: Alignment.Vertical | Alignment.something
>>    }
>>
>> there is no way for you to remove the name lookups for "Alignment", "Vertical", and "something". Also, there is no way for you to distinguish "Types" (e.g. Item, Rectangle, and co...) from "Enums" (in our case "Alignment"). That means, you cannot build the correct list of dependencies when loading a QML Component.
>
> I didn't think this fully through yet, but it looks that it might work..:
>
> What we could do is to elevate QML enums to (nearly) QML type status. The drawback is that an enum has to be in its own file, but it solves the dependency problem. It also does not allow for "inline" or "local" enums. An example:
>
> Alignment.qml:
>   enum Alignment { // or possibly only "enum {", although I think readability suffers
>     vertical // automatically assigned string is "vertical"
>     horizontal: "horizontal"
>   }
>
> We could use the static nature of QML objects (and then also enums) to have an engine do lookups once when loading. Going a bit further, when an enumerator is used, I think we could replace the enumerators with their string representation. That would also make them compatible with existing properties that expect strings.
>
> About the scoping: inserting the enumerators into the parent scope (à la C/C++) will give a (big) performance penalty. It would mean that all files in a package need to be loaded (or at least peeked at) just to find out if they define an enum.
>
> The question is if the above adds any value over something you can already do:
>
> Alignment.qml:
>   QtObject {
>     property string vertical: "vertical"
>     property string horizontal: "horizontal"
>   }
>

I don't think it adds the real value, which comes from just matching
C++ expectations. Enums help out in C++ because they're A)
high-performance B) high-readability and C) Object-Oriented. By
putting enums in their own files as their own types we lose most of C
(and some of A) because they're no longer attached to the object they
are conceptually associated with. The C++ enum State { On, Off,
Automatic } isn't very great or clear if it's in the global namespace,
but could make sense if it's attached to a class (e.g.
MotorControl::State). You also lose the compatibility of matching C++
syntax: A C++ type has all its enums on the type name (e.g.
Text.AlignVertical) wheras here each QML enum has its own type (e.g.
Align.vertical) which is not the same syntax.

I'm beginning to think there's minimal value in bringing first class
enum support to QML. In a dynamic language it doesn't come with the
same clear performance gains as compiled C++, and there are plenty of
other ways to write readable code.
Enums can be left for C++ generated types only.

--
Alan Alpert