Zulip Chat Archive

Stream: general

Topic: mixin and data class names

Yury G. Kudryashov (Feb 11 2022 at 04:37):

Should we fix some naming convention for data and Prop-valued mixin classes?

Yury G. Kudryashov (Feb 11 2022 at 04:38):

E.g., we have docs#has_involutive_star (data) and docs#has_continuous_mul (prop mixin)

Eric Wieser (Feb 11 2022 at 08:46):

My preference would be to use is_ for Prop and has_ for Type, but that might be quite an invasive change.

Eric Wieser (Feb 11 2022 at 08:48):

Under that scheme, has_continuous_mul would become mul_is_continuous or is_continuous_mul

Yaël Dillies (Feb 11 2022 at 08:51):

What about continuous_mul_class on the model of smul_comm_class?

Eric Wieser (Feb 11 2022 at 08:52):

The _class suffix feels like noise to me - I'd lean towards trying to purge it as part of the same renaming

Yaël Dillies (Feb 11 2022 at 08:53):

is_comm_smul and is_assoc_smul, then?

Eric Wieser (Feb 11 2022 at 08:53):

Well is_scalar_tower already starts with is_ and avoids class, so no need to rename that to is_assoc_smul?

Yaël Dillies (Feb 11 2022 at 08:55):

But it's not a very descriptive name.

Yaël Dillies (Feb 11 2022 at 08:57):

I know you're trying to save your FMM paper from deprecation :stuck_out_tongue_closed_eyes:

Moritz Doll (Feb 11 2022 at 14:20):

I find the is_ convention really nice, but for some topology stuff it came up that is_compact is for sets so compact_space can only be renamed to is_compact_space and under that convention we would get stuff like is_locally_convex_space which is really long.

Moritz Doll (Feb 11 2022 at 14:21):

(and the _space is somewhat redundant)

Kyle Miller (Feb 11 2022 at 17:15):

I feel like this had been discussed before, but maybe not for classes. Two related threads:

Last updated: Aug 03 2023 at 10:10 UTC