That’s certainly an improvement, but why “formIntersection” instead of
"intersect" (in analogy to “subtract”)?
- 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
“Those with side-effects should read as imperative verb phrases”
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).
- “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.
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
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? Then why should you expect that in the mutating case?
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)