Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 27, 2004 request: overload "in" | ||||
---|---|---|---|---|
| ||||
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. |
July 27, 2004 Re: request: overload "in" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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. > > |
July 28, 2004 Re: request: overload "in" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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. |
July 28, 2004 Re: request: overload | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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 |
July 28, 2004 Re: request: overload | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane 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
|
July 28, 2004 Re: request: overload | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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. |
July 28, 2004 Re: request: overload "in" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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/ |
July 29, 2004 Re: request: overload "in" | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | "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. |
July 29, 2004 Re: request: overload | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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 |
Copyright © 1999-2021 by the D Language Foundation