Add exception to a rule for class that contains only static members.

[polina-c]

Classes like this happen so often that it worse mentioning them as exception: https://api.dart.dev/stable/3.0.6/dart-developer/Service/Service.html

[github-actions]

Visit the preview URL for this PR (updated for commit 022bc98):

https://dart-dev--pr5077-polina-c-patch-1-in77qeqy.web.app

_{(expires Mon, 31 Jul 2023 20:07:04 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: d851bc446d3c4d7394c5406c6f07255afc7075f3}

[a-siva]

Should it be singleton objects instead of single instance objects ?

[munificent]

Can you give an example of what you mean?

[bkonyi]

Assuming I'm understanding this correctly, I'm not sure it's even worth mentioning the exceptions.

With enhanced enums, there's really no reason to have create new classes of constants, and "enum-like types" are also covered by the functionality introduced with enhanced enums. "Single instance" objects are just singletons and by definition are of a type that is instantiated at least once, making their inclusion in this list of exceptions unnecessary.

[polina-c]

Should it be singleton objects instead of single instance objects ?

'singletone' is a pattern that is useful when exactly one object is needed. So, 'singletone' is a pattern, and 'single object' is a situation, the same as 'when exactly one object is needed', but shorter.

We need situation here. So, I think 'single object' works better.

Am i missing something?

[polina-c]

Can you give an example of what you mean?

https://api.dart.dev/stable/3.0.6/dart-developer/Service/Service.html

[polina-c]

Assuming I'm understanding this correctly, I'm not sure it's even worth mentioning the exceptions.

With enhanced enums, there's really no reason to have create new classes of constants, and "enum-like types" are also covered by the functionality introduced with enhanced enums. "Single instance" objects are just singletons and by definition are of a type that is instantiated at least once, making their inclusion in this list of exceptions unnecessary.

Enhanced enums are limited to constants.
You cannot convert this class to enhanced enum: https://api.dart.dev/stable/3.0.6/dart-developer/Service/Service.html

singleton is a pattern to implement single instance
static class with set of static methods and instances is another pattern that implements single instance

So, "Single instance" objects are sometimes implemented as singletons, and sometimes differently.

Makes sense?

[bkonyi]

Can you give an example of what you mean?

https://api.dart.dev/stable/3.0.6/dart-developer/Service/Service.html

That class should just be made abstract since there's no instance members that are useful.

Although... I think having an abstract class with all static members is a technically a smell as well since namespacing should be done using the as <namespace> syntax when importing the library. That's a bit more difficult when it comes to the dart:* libraries, but I digress... :)

[polina-c]

Can you give an example of what you mean?

https://api.dart.dev/stable/3.0.6/dart-developer/Service/Service.html

That class should just be made abstract since there's no instance members that are useful.

Although... I think having an abstract class with all static members is a technically a smell as well since namespacing should be done using the as <namespace> syntax when importing the library. That's a bit more difficult when it comes to the dart:* libraries, but I digress... :)

Yes, you can import a library with a namespace to create grouping. However, it means manual crafting (opposite to just adding import with quick fix), that have to be consistent across the client package, i.e. the same namespace should be used everywhere.

And, meaningful grouping for static methods and variables, provided by the package authors, really helps to navigate the code, taking advantage of InteliSense.

May be some day we should stop demonizing namespacing and introduce keyword 'namespace' to use instead of 'class'?...

[jakemac53]

Am i missing something?

Yes, this isn't a Singleton, there is no instance at all. In fact, the Service class is exactly what this rule is advising against, it is a direct violation of the suggestion.

As mentioned above, if this was a singleton it would have a constructor (probably private) and an instance, and then it would be allowed to have these methods.

May be we should stop demonizing namespacing and introduce keyword 'namespace' to use instead of 'class'?...

You can use an extension with static members instead to create a more pure namespace without introducing a type that has no instances. And probably the lint won't trigger either. It is still going against the spirit of this guideline, but it is arguably a better way of creating a namespace, if you feel one is necessary.

[polina-c]

Am i missing something?

Yes, this isn't a Singleton, there is no instance at all. In fact, the Service class is exactly what this rule is advising against, it is a direct violation of the suggestion.

Service is conceptually an object, "a thing". But, as there is no state, there is no need to instantiate it, so there is no need to implement Singleton pattern. However, per me, it makes perfect sense to define abstract class to describe behavior of this "thing". Anything wrong?

[jakemac53]

However, per me, it makes perfect sense to define abstract class to describe behavior of this "thing". Anything wrong?

The "wrong" part is described in the rule - In idiomatic Dart, classes define kinds of objects. A type that is never instantiated is a code smell. For instance you can now do void myMethod(Service thing) and that function is valid to write but can never be called because there are never any instances of that type.

This is why the extension approach is arguably better, it doesn't introduce this extra Type into the program.

I do think there are valid reasons you might want a namespace in Dart, although I wouldn't use them heavily. This rule isn't a don't, it's an avoid, so if you think you have a good reason to create a namespace go ahead. But you might need to explain to the reviewer your justification for that. And if you are enforcing avoid_classes_with_only_static_members then you will have to ignore it. Or just use an extension to avoid the lint.

[polina-c]

Thanks to everybody for discussion!