digitalmars.D.bugs - request: overload "in"
- "Ben Hinkle" <bhinkle mathworks.com> Jul 27 2004
- "Walter" <newshound digitalmars.com> Jul 27 2004
- Stewart Gordon <smjg_1998 yahoo.com> Jul 28 2004
- Arcane Jill <Arcane_member pathlink.com> Jul 28 2004
- Andy Friesen <andy ikagames.com> Jul 28 2004
- Stewart Gordon <smjg_1998 yahoo.com> Jul 28 2004
- Regan Heath <regan netwin.co.nz> Jul 28 2004
- "Walter" <newshound digitalmars.com> Jul 28 2004
- Sean Kelly <sean f4.ca> Jul 29 2004
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
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
overloadable on the container - named something like opIn. I don't think opIn_r is needed.
Jul 27 2004
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. 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
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
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
Stewart Gordon <smjg_1998 yahoo.com> 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
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. 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
"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. 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
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