On 13 Aug 2018, at 18:12, Giuseppe D'Angelo via Development 
<development@qt-project.org> wrote:
> 
> Il 13/08/2018 16:40, Tor Arne Vestbø ha scritto:
>> Or:
>>   if (event->device()->pointerType() != QQuickPointerDevice::Finger
>> Gives me all the info I need, and having to type or read this instead is 
>> worse in my opinion:
> 
> This is actually against the old "non-enum class" coding standards: one must 
> repeat the enumeration name in the enumerators.

Just because the old standard was also promoting less readable/writable code 
doesn’t make it a good thing that we should keep 😊 

The coding standard was likely based on global enums, and somehow we didn’t 
account for enums inside classes. Even today 
https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values doesn’t 
mention enums inside classes, and the example only shows global enums.

>>   if (event->device()->pointerType() != 
>> QQuickPointerDevice::PointerType::Finger &&
>> I think we should revisit this policy, and only use it when there’s actually 
>> a clash.
> 
> Which is always "too late" if we're talking about public APIs, as they're set 
> in stone.

Of course. I’m just arguing that we shouldn’t continue down this road now that 
we’ve learned that the coding standard produces worse results for the specific 
case of enums inside classes.

>  In the meanwhile, I would not work around it -- we need *some* enum scoping 
> anyhow, and enum classes are the simplest way possible to not forget about it.

Enum scoping is already achieved by the enum living inside a class. You already 
have your goal met 😊 If it’s a global enum, sure, make it a class enum instead 
of QQuickPointerDevice::FingerPointerType. And if it’s inside a class, and 
clashes, sure, make it a class enum. But for the common case, let’s prioritise 
readability/writability. 

Tor Arne 
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to