> -----Original Message-----
> From: Tor Arne Vestbø
> Sent: Monday, 13 August 2018 16:40
> To: Alex Blasche <alexander.blas...@qt.io>
> Cc: development@qt-project.org; Simon Hausmann <simon.hausm...@qt.io>
> Subject: Re: [Development] Naming convention for (scoped) enums
>
> Bringing this up again in light of e.g. https://codereview.qt-
> project.org/#/c/235167/
>
> When I gave my support to this I thought we were talking about global enums.
I was certainly not limiting myself to those only. That's just a coincidence
that I chose a global enum for the policy.
> I
> do not think that using class enums inside existing classes is a win for code
> readability/writability:
>
> When you have
>
> switch (point->state()) {
>
> It's pretty obvious what case QQuickEventPoint::Pressed: refers to. being
> overly
> explicit with case QQuickEventPoint::State::Pressed: just adds more to type
> for
> no reason.
Similar to Guiseppe, I would argue that the above enum does not comply with the
convention for unscoped enums either. The enum value would have to repeat at
least some part of the enum type. That's a rule that has existed for decades
now. Therefore QQuickEventPoint::State::Pressed is no more verbose than
QQuickEventPoint::PressedState.
In summary, there is very little verbosity added even by existing rules. Mind
you, Qt has always favoured readability and accepted verbosity as a consequence
in times of code completion. There is one more very important aspect. Scoped
enums can have dedicated types and are type safe. This could have easily caught
issues like (which coincidently was pointed out to me this morning):
https://codereview.qt-project.org/#/c/236736/
And I believe that is a very good reason to still prefer scoped enums.
--
Alex
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
