www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - request: overload "in"

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
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.
Jul 27 2004
parent reply "Walter" <newshound digitalmars.com> writes:
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.
Jul 27 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 28 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jul 28 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
Jul 28 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jul 28 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
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/
Jul 28 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"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.
Jul 28 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Jul 29 2004