Von meinem iPhone gesendet > Am 02.09.2016 um 17:56 schrieb Thorsten Seitz via swift-evolution > <[email protected]>: > >> Am 24.08.2016 um 21:35 schrieb Xiaodi Wu via swift-evolution >> <[email protected]>: >> >>> On Wed, Aug 24, 2016 at 1:59 PM, Jonathan Hull <[email protected]> wrote: >>> >>>> On Aug 24, 2016, at 7:48 AM, Xiaodi Wu <[email protected]> wrote: >>>> >>>>> On Wed, Aug 24, 2016 at 3:39 AM, Jonathan Hull <[email protected]> wrote: >>>>> >>>>>> On Aug 23, 2016, at 8:35 AM, Xiaodi Wu <[email protected]> wrote: >>>>>> >>>>>>> On Tue, Aug 23, 2016 at 3:02 AM, Jonathan Hull <[email protected]> wrote: >>>>>>> >>>>>>>> On Aug 22, 2016, at 11:32 PM, Xiaodi Wu <[email protected]> wrote: >>>>>>>> >>>>>>>>> On Mon, Aug 22, 2016 at 11:59 PM, Jonathan Hull via swift-evolution >>>>>>>>> <[email protected]> wrote: >> >>> >>>> Protocols are not merely a vehicle for delivering a reusable bag of code. >>>> One of its most essential purposes is to constrain the shape or API of its >>>> conforming types. Therefore, it is a feature, not a bug, that with every >>>> choice of name in a protocol you foreclose the possibility of composing >>>> that protocol with others that might have colliding names. >>>> >>>> Currently, if you the protocol vendor have made the decision that `image` >>>> "makes the most sense in the protocol's context", you must have considered >>>> whether it would be absurd for a conforming type to have another use for >>>> `image`. > > I find it a little bit strange to require from a protocol designer to foresee > all future uses of a protocol. IMO protocols are not bags of code but > encapsulate a certain (typically fine grained) semantic. How this semantic > will be coupled with other semantics (i.e. protocols) is widely open. I agree. Why should a language that supports: 1. type aliases and retroactive modeling (even adding protocol conformance to existing types to the extent that basic types implement user library protocols) and 2. discuss to add type aliases for generic types and existentials as well as 3. something like *new type* for type aliases with nominal typing... not allow to rename methods? The argument that protocols have to be designed by the "protocol vendor" foreseeing all its usages does not hold for every case. A language with type aliases and retroactive modeling allows for domain specificity via context dependent changes to a and renaming of a type. This can be used for internal DSLs (domain specific languages) and the like. I know that my point here is orthogonal to the original problem of renaming because of name clashes between protocols, but I address the more general question whether renaming of associated types, methods and the like wouldn't be a good (and consequent) thing. All the best Johannes Von meinem iPhone gesendet
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
