4 ms·

Aliases weren't only proposed as a way to implement gradual repairs (and the proposal, also, is for "a way to implement gradual repair", not so much "aliases").

Aliases weren't only proposed as a way to implement gradual repairs (and the proposal, also, is for "a way to implement gradual repair", not so much "aliases"). There are several non-transitionary use cases given as a justification for aliases, when they where initially proposed. Examples are a) implementing the protobuf "public import" feature in generated code, b) providing drop-in extension packages for other people's code (for example golang.org/x/image/draw is an extension of image/draw) and c) exposing APIs from internal packages selectively. Personally, at least b) is definitely something I would use them for. It's just that a lot of people didn't clearly understand what the refactoring problem is, that aliases would solve ("just use a tool for rewriting things" was a common response, or "use versions") and how aliases solve it. So, this proposal is taking a step back; instead of necessarily pushing aliases, it now describes the refactoring problem that aliases solve and seeks a) consensus that this is a problem that go should solve systematically and b) what the mechanism is, that it should solve them with. Aliases are one proposed way. That's why I would be really annoyed, if something like compiler warnings or so would be introduced when you use them; if go gets aliases, I'd consider it stupid not to use them for all the other things that they are a good solution for. And I would use them as such and if people complained about compiler warnings, tell them to complain to the go team that they put warnings in for something that shouldn't be warned about.

blixt 10y ago
These are fair points and I must've missed the elaboration on them when I looked at the proposal for aliases, as I was left with the feeling they were being pushed forward mainly to solve the gradual repair issue. I guess I have two points to make: 1) try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues 2) if you do see an opportunity to apply a general solution, exhaust every use case of that solution and rewrite the problem statement to apply to all those use cases As for being really annoyed if there were warnings, that was exactly my point. :) Label them as something more specific (a solution to the repair problem) and make it difficult to use them for something else. That doesn't exclude a future, more generic solution – it just avoids unaccounted for problems.
- Merovius 10y ago
  > try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues Orthogonality is one of the key design goals of go. That means a) keep the intersections of use cases of features low and b) maximize the space you can span with them. Having "contained solutions" will inevitably lead to a more complicated language (infinitely many contained problems with a contained solution each means diverging number of contained solutions) and won't span a large problem space by definition. You want to solve as many problems as possible with as little features as possible. > As for being really annoyed if there were warnings, that was exactly my point. :) Label them as something more specific (a solution to the repair problem) and make it difficult to use them for something else. You misunderstood my point. You are not making it difficult, you are simply making it annoying (to both me and my users). Warnings would have exactly zero influence on how much and for what I would use aliases in practice (thus totally failing your goal), they would just make me hate the person who proposed them (dunno. Maybe that's a plus for you? Doesn't seem like that to me). Solving many problems with one solution is not a bug, it's a feature. Interfaces do not only solve one problem. Embedding doesn't only solve one problem. A language feature that only has one specific use case is just a wart. For example: python's "pass" keyword is an incredible wart. It's only use is, to make the language unambiguous to the parser, but it doesn't actually serve any purpose. At the same time, you are putting in a keyword; no one will ever be able to use that as an identifier. The same, actually, goes for a lot of other features of python. It's pretty much the epitome of insular features: http://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...

blixt 10y ago

These are fair points and I must've missed the elaboration on them when I looked at the proposal for aliases, as I was left with the feeling they were being pushed forward mainly to solve the gradual repair issue. I guess I have two points to make: 1) try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues 2) if you do see an opportunity to apply a general solution, exhaust every use case of that solution and rewrite the problem statement to apply to all those use cases As for being really annoyed if there were warnings, that was exactly my point. :) Label them as something more specific (a solution to the repair problem) and make it difficult to use them for something else. That doesn't exclude a future, more generic solution – it just avoids unaccounted for problems.

Merovius 10y ago
> try to make a contained solution for a contained problem because the general solution may carry with it a number of unforeseen issues Orthogonality is one of the key design goals of go. That means a) keep the intersections of use cases of features low and b) maximize the space you can span with them. Having "contained solutions" will inevitably lead to a more complicated language (infinitely many contained problems with a contained solution each means diverging number of contained solutions) and won't span a large problem space by definition. You want to solve as many problems as possible with as little features as possible. > As for being really annoyed if there were warnings, that was exactly my point. :) Label them as something more specific (a solution to the repair problem) and make it difficult to use them for something else. You misunderstood my point. You are not making it difficult, you are simply making it annoying (to both me and my users). Warnings would have exactly zero influence on how much and for what I would use aliases in practice (thus totally failing your goal), they would just make me hate the person who proposed them (dunno. Maybe that's a plus for you? Doesn't seem like that to me). Solving many problems with one solution is not a bug, it's a feature. Interfaces do not only solve one problem. Embedding doesn't only solve one problem. A language feature that only has one specific use case is just a wart. For example: python's "pass" keyword is an incredible wart. It's only use is, to make the language unambiguous to the parser, but it doesn't actually serve any purpose. At the same time, you are putting in a keyword; no one will ever be able to use that as an identifier. The same, actually, goes for a lot of other features of python. It's pretty much the epitome of insular features: http://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...