dart-archive
A library or package for annotations, helpers
Should we create a library or package for the following?
Annotations (checked by strong mode):
- final (class, method, field)
- interface (or no interface)
- generic methods?
Type checking:
- typedef T Func0<T>();
- typedef T Func1<T, T1>(T1 t1);
- typedef T Func2<T, T1, T2>(T1 t1, T2 t2);
- ...
Methods
- strong is
- strong as
If we add a final annotation, I don't think it should be specific to strong mode.
I'm not sure what the interface annotation means, but we've been talking locally about being able to annotate our classes with information such as "clients should not subtype this type", "clients should only subtype this type by extending it (but not by implementing or mixing it in)", etc. If that's what this annotation is for, we should design the whole range of options, not just two.
I would prefer to not have annotations for generic methods because I'd prefer to just have them added to the language, but if we think users are going to need them before they can be part of the language, then perhaps we do need them.
I would tend to lean away from generic typedefs like these, preferring types with more meaningful names, unless you're really going to build completely general methods that take them. For example, I'd rather have something like:
typedef bool Filter<T>(T object)
Iterable applyFilter(Iterable iterable, Filter filter)
for functions that return a boolean indicating whether the object should be included/excluded from something than a generic type, resulting in something like:
Iterable applyFilter(Iterable iterable, Func1 filter)
I can't say about the "strong is" and "strong as" because I don't understand them well enough. Would they provide value beyond the normal 'is' and 'as' operators when running in strong mode? Is there a use case for using them when not using strong mode?
If we add a final annotation, I don't think it should be specific to strong mode.
agreed, these seem like useful static checking things (similar to @override)
I'm not sure what the interface annotation means, but we've been talking locally about being able to annotate our classes with information such as "clients should not subtype this type", "clients should only subtype this type by extending it (but not by implementing or mixing it in)", etc. If that's what this annotation is for, we should design the whole range of options, not just two.
+100
I would prefer to not have annotations for generic methods because I'd prefer to just have them added to the language, but if we think users are going to need them before they can be part of the language, then perhaps we do need them.
yeah, exactly, they'd be temporary. FWIW, I don't think it's necessarily a bad thing to use annotations as a way of vetting a potential future language feature.
I would tend to lean away from generic typedefs like these, preferring types with more meaningful names, unless you're really going to build completely general methods that take them.
In C# we had generic Action and Func, from my own experience and people I've worked with, they were super useful. Yeah, often it's nice to name things. Sometimes it's not worth it, because parameter names/context already makes the intent obvious. Sometimes you're working on something quick and dirty, and it doesn't matter. Other times you're designing an API for millions of people and you better think really really hard about every single API name. I guess my point is, there's a time and a place for different styles.
I can't say about the "strong is" and "strong as" because I don't understand them well enough. Would they provide value beyond the normal 'is' and 'as' operators when running in strong mode? Is there a use case for using them when not using strong mode?
They'd be a sound is/as check. So if you ask [1,'hi'] is List<int>, it's going to say no.
package:func already has annotations for Func0, Func1, Func2, ..
@strongIs, @strongAs and @final
look like good candidates for a dart: package of annotations.
they could be rexported from the dart: package to a
package:ddc_annotations or whatever you prefer but it might be nice to have a fixed
dart: name so it is simple to reliably verify you have the correct annotation in dart:js and the analyzer.
