in case it hasn't been requested before, I think the "in" operator should be overloadable on the container - named something like opIn. I don't think opIn_r is needed.

It's a good idea.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce68qk$2hgc$1@digitaldaemon.com...
> in case it hasn't been requested before, I think the "in" operator should
be
> overloadable on the container - named something like opIn. I don't think opIn_r is needed.
>
>

Walter wrote:
> It's a good idea.
> 
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce68qk$2hgc$1@digitaldaemon.com...
> 
>> in case it hasn't been requested before, I think the "in" operator
>> should be overloadable on the container - named something like
>> opIn. I don't think opIn_r is needed.

It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6103

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

In article <ce7sct$48h$1@digitaldaemon.com>, Stewart Gordon says...
>
>>> in case it hasn't been requested before, I think the "in" operator should be overloadable on the container - named something like opIn. I don't think opIn_r is needed.
>
>It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.

So call it opIn_r() for naming consistency. Just don't provide an opIn() as
well.

Too easy?
Jill

Arcane Jill wrote:
> In article <ce7sct$48h$1@digitaldaemon.com>, Stewart Gordon says...
> 
>>>>in case it hasn't been requested before, I think the "in" operator
>>>>should be overloadable on the container - named something like
>>>>opIn. I don't think opIn_r is needed.
>>
>>It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.
> 
> 
> So call it opIn_r() for naming consistency. Just don't provide an opIn() as
> well.
> 
> Too easy?

This line of thought leads me to think that, no matter what you do, you're going to confuse somebody.  Requiring or forbidding the _r suffix seems sort of like the dummy int argument that C++ uses to distinguish between postinc and preincrement.

A more descriptive name might be cleaner:

    class Barrel {
        // "if this contains the value"
        bool opContains(T value) {
            return search(value) !== null;
        }
        T* search(T value) { ... }
    }

    Barrel!(char[]) barrel = new ...

    // same as bucket.opContains("monkeys")
    if ("monkeys" in barrel) {
        ...
    }

This way, the name is a bit more explicit in describing what it is asking.  The _r notion doesn't come into play, because the name is at a higher conceptual level than the operator it overloads.  Nobody's asked for opCmp_r yet. :)

The downside to this, of course, is that you lose the guessability. (that is, the overload name isn't going to be the first wild guess that pops into a new/forgetful programmer's head)

 -- andy

Andy Friesen wrote:
<snip>
> This way, the name is a bit more explicit in describing what it is asking.  The _r notion doesn't come into play, because the name is at a higher conceptual level than the operator it overloads.  Nobody's asked for opCmp_r yet. :)

I guess that's yet another drawback of Object.opCmp - it prevents opCmp_r from being invented.

Except that, if Object.opCmp were finally got rid of, then opCmp would presumably work according to the commutativity rules, except with the result negated.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Wed, 28 Jul 2004 10:41:49 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> Walter wrote:
>> It's a good idea.
>>
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce68qk$2hgc$1@digitaldaemon.com...
>>
>>> in case it hasn't been requested before, I think the "in" operator
>>> should be overloadable on the container - named something like
>>> opIn. I don't think opIn_r is needed.
>
> It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6103

I reckon the solution is to remove 'in' and replace it with 'has' or 'contains' so that you write:

if (container has value)

rather than

if (value in container)

then opHas makes sense for a container.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ce7sct$48h$1@digitaldaemon.com...
> Walter wrote:
> > It's a good idea.
> >
> > "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce68qk$2hgc$1@digitaldaemon.com...
> >
> >> in case it hasn't been requested before, I think the "in" operator should be overloadable on the container - named something like opIn. I don't think opIn_r is needed.
>
> It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6103

Confusing, yes. But not confusing to the user of the class, and I would expect the class designer to be more sophisticated.

In article <ce7sct$48h$1@digitaldaemon.com>, Stewart Gordon says...
>
>Walter wrote:
>> It's a good idea.
>> 
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce68qk$2hgc$1@digitaldaemon.com...
>> 
>>> in case it hasn't been requested before, I think the "in" operator should be overloadable on the container - named something like opIn. I don't think opIn_r is needed.
>
>It's been discussed quite a bit already.  The trouble is that if opIn worked from the container side, then while logical to the purpose, it would create a confusing semantic inconsistency with other operators.

So it's right associative.  Offer opIn_r only.  Not all binary operators are commutative anyway.


Sean