fortran-lang / stdlib

Fortran Standard Library
https://stdlib.fortran-lang.org
MIT License
1.06k stars 164 forks source link

Consistent naming of derived types in stdlib_bitset #332

Open milancurcic opened 3 years ago

milancurcic commented 3 years ago

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
awvwgk commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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?