> Am 31.03.2016 um 19:53 schrieb Dave Abrahams <[email protected]>: > > >> on Thu Mar 31 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote: >> >> Am 30. März 2016 um 17:48 schrieb Dave Abrahams <[email protected]>: >> >> on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote: >> >> Am 30.03.2016 um 16:49 schrieb Dave Abrahams >> <[email protected]>: >> >> on Wed Mar 30 2016, Thorsten Seitz >> <tseitz42-AT-icloud.com> wrote: >> >> That's certainly an improvement, but why >> "formIntersection" instead of >> >> "intersect" (in analogy to "subtract")? >> >> 1. Consistency with union, which is more closely related than >> subtract. >> >> I'd prefer consistency with the verb rule here >> >> Which rule is that? As far as I can tell, this is consistent with all >> the rules. >> >> "Those with side-effects should read as imperative verb phrases" > > “form <some-noun-phrase>” is an imperative verb phrase. > >> I expect a common verb to be chosen over an awkward, constructed one, >> although I have to admit that the verb "intersect" is used only very >> seldom if at all in set theory or geometry. Therefore you might have >> a point with "intersect" having the wrong implication, but see below. >> >> (using formXXX only as last resort). >> >> Though I prefer not to, you can look at this as a last resort if you >> like; the alternative you're proposing has the wrong implication, so it >> is not a candidate. It would be like using “remainder” as a verb for >> integers. Yes, it's a legitimate verb, but it means the wrong thing >> (see retail). >> >> 2. "Intersect" actually has the wrong meaning as an >> imperative. If you >> >> tell set A to intersect set B, and then ask whether A intersects B >> >> (!A.isDisjoint(with: B)), you would expect an answer of true. >> >> Sorry, but I do not agree. With that reasoning I would have to expect >> >> a.intersection(b) to be not empty. >> >> Yes, that's exactly what I'm saying. If you tell A to intersect B, >> presumably when the call completes, A intersects B (i.e. has a non-empty >> intersection). That would imply an implementation like, e.g. >> >> With a.intersection(b) I meant to extend your reasoning to the >> non-mutating method. >> >> You surely do not expect the intersection of a and b to be non-empty >> when calling the non-mutating method? > > No I do not. > >> Then why should you expect that in the mutating case? > > for the same reason that > > shape1.encloses(shape2) > > might return true or false but > > shape1.enclose(shape2) > > has to change shape1 so it encloses shape2.
Thanks! That's a very good example! -Thorsten >> Is it because the noun implies a current state whereas the verb should >> be read as a command demanding to create a certain state? (I'm not a >> native speaker, so please bear with me) > > I think that's a pretty good explanation. > > HTH, > > -- > Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
