I wasn’t aware of this being a thing in Ruby - interesting! Perhaps it is not so untested territory after all. :) Would be interesting to see if whatever prompted your hatred of it there is due to how it works in Ruby vs. the idea itself or not, though. Not sure how one would go about determining that, though. Or if that’d even be a useful result.
l8r Sean > On Jun 29, 2016, at 12:14 PM, David Hart <[email protected]> wrote: > > I have experience using aliases in Ruby and they are one of the aspects of > the language I hated with a passion. They can be very confusing, and increase > the difficulty of learning the APIs and QuickHelp is not always there to > help. To me, they sound like a convenience for the code writer but a nuisance > of the reader. And Swift has always tried to improve its readability over its > writability. > > On 29 Jun 2016, at 18:19, Sean Heber via swift-evolution > <[email protected]> wrote: > >>> Agreed. I'd have to be convinced that having aliases provide overwhelming >>> wins at the call site that could not be achieved through renaming. Although >>> aliasing could be very neat in certain circumstances, I fear that admitting >>> such a facility to the language is an "out" that would discourage >>> exploration of the most appropriate method names and consensus-building in >>> favor of "you'll have yours and I'll have mine," which would be fatal for >>> building a coherent set of APIs. >> >> It would probably be quite difficult to prove (although that doesn’t mean it >> isn’t worth trying) that aliases would be an overwhelming win because >> everyone has different tolerances for impedance mismatches. In many ways, it >> is that difference of tolerance that is the issue here (and in a few other >> threads). >> >> I personally have no desire to fragment things more than necessary, but I >> also really want code to read fluently. These goals seem to be at odds and, >> I speculate, they are at odds in ways that are impossible to solve with a >> single solution. Human languages have a lot of redundancy and variety for a >> reason, and we’ve taken the stance that Swift should read with a kind of >> “flow” that we usually only associate with human languages. This means that >> there are likely going to have to be concessions made to Swift that one >> might not ordinarily see in a programming language. (IMO) >> >> The argument that aliases would be “fatal” for building coherent API doesn’t >> seem to tell the whole story to me. After all, every program ultimately has >> it’s own “language” of sorts that is built up from the building blocks of >> the standard library and other included frameworks. There’s a unique mix of >> the usage of certain words, constructs, names in each program that is a >> reflection of the programmers who have built the program and each one reads >> differently no matter how hard we might try to have only “one true way” to >> express a thing. >> >> To me, one of the nicer aspects of having aliases encoded in the API as >> function attributes is that, in the case of the standard libraries, they >> would be decided and bikeshedded by the usual suspects and then effectively >> locked into place. There’s still control on the extent of use of this >> feature. You cannot add an alias by way of an extension in your own code, >> for example, and I think that’s a fine tradeoff. It would be surgically used >> and, mostly, only by the core team/standard lib API designers and by those >> who wish to experiment. I don’t know if that’s a big win or not. To me, this >> feels like mostly untested territory. >> >> l8r >> Sean >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
