SetAlgebra naming update


(Thorsten Seitz) #1

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”

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).

  1. “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
(see retail).

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)

-Thorsten

···

Am 30. März 2016 um 17:48 schrieb Dave Abrahams dabrahams@apple.com:

Am 30.03.2016 um 16:49 schrieb Dave Abrahams dabrahams@apple.com:

on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:


(Dave Abrahams) #2

                        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.

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,

···

on Thu Mar 31 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

Am 30. März 2016 um 17:48 schrieb Dave Abrahams <dabrahams@apple.com>:
    on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
                Am 30.03.2016 um 16:49 schrieb Dave Abrahams <dabrahams@apple.com>:
                        on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

--
Dave


(Thorsten Seitz) #3

                       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

···

Am 31.03.2016 um 19:53 schrieb Dave Abrahams <dabrahams@apple.com>:

on Thu Mar 31 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
Am 30. März 2016 um 17:48 schrieb Dave Abrahams <dabrahams@apple.com>:
   on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:
               Am 30.03.2016 um 16:49 schrieb Dave Abrahams <dabrahams@apple.com>:
                       on Wed Mar 30 2016, Thorsten Seitz <tseitz42-AT-icloud.com> wrote:

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