Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistent naming of derived types in stdlib_bitset #332

Open
milancurcic opened this issue Mar 11, 2021 · 6 comments
Open

Consistent naming of derived types in stdlib_bitset #332

milancurcic opened this issue Mar 11, 2021 · 6 comments
Labels
documentation Improvements or additions to documentation specification Discussion and iteration over the API

Comments

@milancurcic
Copy link
Member

So far we've been using a _type suffix for our derived types, but not 100% consistently.

We have a logger_type, a string_type, a bitset_type, but also bitset_64 and bitset_large types that extend bitset_type.

Should bitset_64 and bitset_large be renamed to bitset_64_type and bitset_large_type for consistency?

For background context, we're using a suffix in derived type names to allow using the base name for the instance itself, for example:

type(logger_type) :: logger
@milancurcic milancurcic added the question Further information is requested label Mar 11, 2021
@awvwgk
Copy link
Member

awvwgk commented Mar 11, 2021

I just proposed a derived type named string_class in #333. Rather than suffixing it with _type I used _class to highlight that it is indeed intended for class polymorphic usage. But generally we should make the suffixes agreed on in #26 mandatory for all derived types.

@awvwgk awvwgk added specification Discussion and iteration over the API and removed question Further information is requested labels Mar 27, 2021
@awvwgk awvwgk changed the title Consistent naming of derived types Consistent naming of derived types in stdlib_bitset Mar 27, 2021
@awvwgk awvwgk added the documentation Improvements or additions to documentation label Mar 27, 2021
@awvwgk
Copy link
Member

awvwgk commented Mar 27, 2021

Let's make this a real task to rename the stdlib_bitset types to conform with the style guide agreed on in #26. Also the _type suffix for derived type names should be included in the style guide.

@ivan-pi
Copy link
Member

ivan-pi commented Mar 27, 2021

Personally, I am not (yet) convinced by the consistency argument.

Then again, if the _type suffix becomes the convention, I will be forced into the habit of renaming:

use stdlib_bitset, only: bset => large_bitset_type

This will be equally annoying as all the renaming in Python scripts (e.g. import matplotlib.pyplot as plt) which I blindly accept and never complain about.

@milancurcic
Copy link
Member Author

See #225. There was overall strong support for using a suffix for derived type names. But if there is more support for not using a suffix (as was my preference as well), let's revisit it. I think there should be naming consistency within stdlib.

@ivan-pi
Copy link
Member

ivan-pi commented Mar 27, 2021

I just re-read that thread, and the opinion I liked the most was from @wclodius2 :

FWIW in regards to type naming, I am now of the opinion that is the type name is long or otherwise inconvenient to be used as a variable name it should not have a suffix, but if likely to be used as a variable name it should have the _t suffix.

(I would prefer to settle on _type as the suffix when the base name is short. The standard also does not follow a consistent naming scheme, e.g. c_funptr vs lock_type, so I don't think we should require that either.)

Maybe two exceptions to suffixing with _type could be:

  1. When the base name is already very long, and it is unlikely to be used as a variable name.
  2. When it has some kind of prefix (examples of this are the types in iso_c_binding).

I guess the convention to use _type consistently would "ease" developer efforts, by eliminating this type of discussion for each new derived type we want to introduce and allow us to move on.

@wclodius2
Copy link
Contributor

I have decided to address issue #383 and while I am modifying the bitsets code I can also change the type names. Is there a consensus that bitset_64 and bitset_large be renamed to bitset_64_type and bitset_large_type for consistency?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation specification Discussion and iteration over the API
Projects
None yet
Development

No branches or pull requests

4 participants