Hi,
On Wed, Dec 12, 2012 at 10:51 PM, Charley Bay <charleyb...@gmail.com> wrote:
> Unto all so did sayeth Alan:
>
>> > What should enumeration declarations in QML look like?
>>
>
> Did respondeth Erik:
>
>> And, also important: how much slower is it allowed to be than the current
>> implementation?
>>
>> I remembered that there was talk about enums in QML before, so I dug
>> around a bit, and behold:
>>
>> 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.
>
>
>> 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.
>>
>
> Ouch. That is quite unexpected.
>
> We seem to have multiple intentions regarding adding "Enums" to QML:
>
> (1) Those with a "native" (C/C++) background may have thought "Enum" to
> be faster than "String" (e.g., "performance-goal")
>
With v4vm, I believe (Lars or Simon can correct me if I'm wrong) every
single time we have a JavaScript expression (well, one which doesn't do
something totally crazy like build a dynamic expression up as a string and
then eval it, but if you're doing that in your code please be aware that
you're the cause of mass kitten suicide) every symbol will be resolved at
compile time where possible (ie, if the evaluation context cannot change).
Thus, once typenames of QML document defined types are resolvable, we
should get great perf from enums.
>
> (2) Some may prefer the "cleaner-look" by using an unquoted "Enum" over a
> quoted string literal
>
If the syntax isn't nice, I don't want it in QML ;-) Times like these I
wish we hadn't included grouped properties :-/
>
> (3) Some may expect a "compile-time" check for (valid) enumerated-values,
> as compared with a "run-time" check with string-lookups (? this may not be
> a real consideration depending on how the QML parsing engine works)
>
As I mentioned earlier, this should be doable in the future. Enums are
looked up from the Q_ENUMS registered with the type with the given type
name, and should be resolvable at compile time (for both binding
expressions and bound signal expressions, and other dynamically added
functions).
>
> (4) Lack of "Enums" in QML is (another) example of how QML might be
> considered a "second-class-citizen" (mentioned by Chris, another example
> being composite types in QML are not backed by a QQmlType and thus are not
> available in JavaScript as are types defined in C++)
>
It is an example of that, but my point was that implementing enums in QML
is meaningless until we have fixed the problem with unresolvable
typenames. This entire thread should be revisited after QTBUG-24799 is
fixed.
Cheers,
Chris.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
