-
Notifications
You must be signed in to change notification settings - Fork 203
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
Syntactic sugar for typedef
#4112
Comments
This is a renaming operator, not just a type alias. Nothing would prevent it from renaming a variable or function. It's not a new idea, it has been known since the |
I agree, but today this can be done anyway with |
My reason against that would be that a rename doesn't expose a declaration. If you expose a name using a With import 'dart:core' as core;
/// A text used by something or other.
typedef Text = core.String; you get to say what the new name means. The core question is which problem this feature solves. Is it having to write a typedef to rename something inside the same library or package, just for convenience? In that case, I don't think the benefit is big enough to warrant a language feature. Just write the typedef once and for all, and import it where you need it. To not have to do the three-step-name-bypass, two imports, one without prefix and with a Is it intended as a way to expose an existing type by another name in a public API? Then I think you should document it, so using a Is it exposting the same declaration under different names (not just the same type, like a type alias)? A type alias has covered that pretty well since it started allowing static member accesses. I'm not seeing the problem that solves. Just to be realistic, language features are not free. They need to carry their own weight, with the benefit they add outweiging the cost of adding them, including opportunity cost. This feature, even if it looks fairly simple, doesn't seem likely to be worth its own design and implementation. The problems it addresses don't happen often enough and the workaround isn't problematic enough, so I expect the net benefit to be low. If people would regularly make mistakes in the workaround, then saving them from a pitfall might increase the value, but this would only save typing. There are other places where one can save typing, more commonly hit, that I'd go for first. Not saying it wouldn't be nice to have. |
I will explain why I gave this issue a thumbs up. I was creating a card game and I want to call "Card" one of the most important project classes. However, it's a Flutter project and Flutter has a class called "Card". Therefore I need to write |
In my opinion, if you are making a card came, you shouldn't be depending on Not saying that I disagree (or agree) with this issue. |
One thing you can do is have your own library: // lib/src/nocard_material.dart
import 'package:flutter/material.dart' as card;
export 'package:flutter/material.dart' hide Card;
typedef FlutterCard = card.Card; and then import that everywhere you would otherwise import That can even be easier to use than having to do |
I may have a library exporting flutter then, thanks Lasse!
Possibly, I can try to import widgets.dart instead of material.dart. |
I think we need improved tooling for this. When I once attempted something similar, the inconvenience of needing to select the correct import - and needing to remember it - is not great. Perhaps we should have some kind of annotation we could use to say that "this export is preferred over importing directly"? Or perhaps that should be its own issue? I'm not sure where it would go though. |
Today if I have two libraries that export classes with the same name, we get
ambiguous_import
if we try to use it. The suggested workarounds are to add an alias to one (or both) imports or to usehide
.Most of the time this is just fine, I'd like to propose a syntactic sugar to make the class names clearer on use.
Today we can do the following:
a.dart
main.dart
I'd like to propose a syntactic sugar for imported elements:
I'm not sure what word to use on
with
, just a suggestion. Using a different word to mean that I don't want toshow
orhide
anything, but I believe this should work onshow
as well.The text was updated successfully, but these errors were encountered: