> On Oct 17, 2017, at 1:36 PM, Benjamin G <benjamin.garrig...@gmail.com> wrote: > > > > On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman <milse...@apple.com > <mailto:milse...@apple.com>> wrote: > > >> On Oct 17, 2017, at 12:54 PM, Benjamin G <benjamin.garrig...@gmail.com >> <mailto:benjamin.garrig...@gmail.com>> wrote: >> >> Thanks for the post, that's the first clear explanation i see on this thread >> for the concepts behind the design for Sequence. >> >> I am a bit afraid that understanding all that is a bit above what to expect >> the average swift developer will guess when he sees functions like "prefix / >> first / elementEqual (or whatever it's called)" on the Set type. >> There is, IMHO, a much higher chance he'll either : >> 1/ not understand anything, or >> 2/ think Sets are in fact secretely ordered sets, or start writing generic >> extensions above Sequence or Collection thinking those protocols are >> synonymous for orderer collections. >> >> 1/ is pretty harmless, but 2/ seems like a source of bug. >> >> My personal opinion after reading all this is that we should simply change >> the name > > Exactly, and that’s what Xiaodi’s proposal does. Confronted with these > complexities, his proposal reasons that a name change is the lessor or evils, > as in the “Proposed solution” section. > >> to sequentiallyEquals > > Xiaodi floated “lexicographicallyEqual” which is accurate and a big > improvement, and I’m liking it more and more. I floated “sequentiallyEquals”, > which I’m liking less and less now. My current preference is for > “elementsOrderedEqual” which I think is more descriptive but unwieldy. On the > other hand, this is a far less common facility, and order matters, so maybe > more verbose names are fine. > > I'm sorry to bring more bikeshedding, but lexicographicallyEqual seems > absolutely atrocious to me. Imagine all the steps required the user of a > Set<Int> to understand why a lexicographicallyEqual function is suggested by > the compiler ?? >
My initial resistance is that lexicographical implies a comparability beyond equality. `lexicographicallyEquals`, then, had me (erroneously) wondering if the “lexicographically” part meant that the elements were presented in lexicographical order and then compared for equality. But, I was in error and this is a wrong interpretation of the term. “abc” is not lexicographically equal to “cba”, and it’s quite a mental leap to think that the order of elements would be presented differently. That’s not to say that others won't have the same misinterpretation and that’s why I’m hoping for a better name. But, if `lexicographicallyEquals` is what we settle on, that’s a huge improvement over `elementsEqual`. > Since you seem to give the kind of answer i'm looking for, do you have any > answer to a previous question i asked regarding the rational for conflating > the iterator with the collection ? > What i mean by that is : i think nobody would have cared if the syntax for > Set was actually > set1.iterator.elementEquals(set2.iterator) > It's a bit more verbose, but the meaning is obvious. To me that reads as meaning something more akin to set1.first == set2.first (whether nil or not). I think what you’re trying to demonstrate is an equality on an iterator that implies equality of iterated elements. But, there could be alternatives: if a Sequence has identity, then perhaps its iterator’s equality should enforce the identity. I may also be completing misunderstanding your question. > I think a reason why people are confused is that the actual design conflates > methods of the "iterator" on the collection type itself. An alternate design > would have been to make collection Sequenceable rather than a sequence > themselves. But i suppose you've thought about that already, so i'm just > curious to know what made you choose the current solution instead. No, I have not thought about it much. I’m a relatively new contributor (a few months) to the standard library, and am just now thinking about such things on an as-needed basis. Personally, I care much more about what operations a data structure provides and how it does it than whatever protocol hierarchy it models. As far as what hierarchy should exist in the standard library, I care much more about pragmatism than purity as the hierarchy’s main benefit is to enable generic programming. I think George Box said it best: “All models are wrong, but some are useful”.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
