www.digitalmars.com         C & C++   DMDScript  

D - opContains

reply Patrick Down <Patrick_member pathlink.com> writes:
A an operator overload for 'in' would be nice.

class Foo
{
bool opContains(char[]) {}
}

Foo f;

if("bar" in f) { }
Jan 20 2004
next sibling parent Vathix <vathix dprogramming.com> writes:
Patrick Down wrote:

 A an operator overload for 'in' would be nice.
 
 class Foo
 {
 bool opContains(char[]) {}
 }
 
 Foo f;
 
 if("bar" in f) { }

Gets my vote. I was thinking of mentioning it several times. Although, I thought of naming it opIn; opContains is good too.
Jan 20 2004
prev sibling next sibling parent reply "C" <dont respond.com> writes:
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }

Jan 20 2004
parent reply Juan C <Juan_member pathlink.com> writes:
I guess if it's an operator "in" makes sense.
But if it's a method "contains" is better...
if ( f.Contains ( "bar" ) ) ...

And personally, I prefer methods rather than bogging a language down with
operators. Especially when the operation is not likely to be used in a larger
expression, as boolean expressions seldom are.

In article <buktne$217e$1 digitaldaemon.com>, C says...
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }


Jan 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Juan C" <Juan_member pathlink.com> wrote in message
news:bul8ct$2id6$1 digitaldaemon.com...
 I guess if it's an operator "in" makes sense.
 But if it's a method "contains" is better...
 if ( f.Contains ( "bar" ) ) ...

 And personally, I prefer methods rather than bogging a language down with
 operators. Especially when the operation is not likely to be used in a

 expression, as boolean expressions seldom are.

In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)
 In article <buktne$217e$1 digitaldaemon.com>, C says...
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }



Jan 21 2004
parent reply "C" <dont respond.com> writes:
I don't really like the double use of 'in' , I doubt this will take but what
about renaming it to 'contains'.

char [ int ] hash;

if ( hash contains "element" ) { }

?

C
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bulf2p$2u6r$3 digitaldaemon.com...
 "Juan C" <Juan_member pathlink.com> wrote in message
 news:bul8ct$2id6$1 digitaldaemon.com...
 I guess if it's an operator "in" makes sense.
 But if it's a method "contains" is better...
 if ( f.Contains ( "bar" ) ) ...

 And personally, I prefer methods rather than bogging a language down


 operators. Especially when the operation is not likely to be used in a

 expression, as boolean expressions seldom are.

In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)
 In article <buktne$217e$1 digitaldaemon.com>, C says...
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }




Jan 21 2004
parent reply The Lone Haranguer <The_member pathlink.com> writes:
If it's not a mathematical operation it shouldn't be an operator.

In article <bumcqt$1ad8$1 digitaldaemon.com>, C says...
I don't really like the double use of 'in' , I doubt this will take but what
about renaming it to 'contains'.

char [ int ] hash;

if ( hash contains "element" ) { }

?

C
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bulf2p$2u6r$3 digitaldaemon.com...
 "Juan C" <Juan_member pathlink.com> wrote in message
 news:bul8ct$2id6$1 digitaldaemon.com...
 I guess if it's an operator "in" makes sense.
 But if it's a method "contains" is better...
 if ( f.Contains ( "bar" ) ) ...

 And personally, I prefer methods rather than bogging a language down


 operators. Especially when the operation is not likely to be used in a

 expression, as boolean expressions seldom are.

In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)
 In article <buktne$217e$1 digitaldaemon.com>, C says...
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }





Jan 21 2004
next sibling parent "C" <dont respond.com> writes:
But we already have many operators that dont fall into that category.

int opCat (  int x)
int opIndex (  int x)
int opCall ( )
int opApply(int delegate(inout uint) dg)

How about , after this one , no more operators ;).

C


"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:bumed2$1cqp$1 digitaldaemon.com...
 If it's not a mathematical operation it shouldn't be an operator.

 In article <bumcqt$1ad8$1 digitaldaemon.com>, C says...
I don't really like the double use of 'in' , I doubt this will take but


about renaming it to 'contains'.

char [ int ] hash;

if ( hash contains "element" ) { }

?

C
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bulf2p$2u6r$3 digitaldaemon.com...
 "Juan C" <Juan_member pathlink.com> wrote in message
 news:bul8ct$2id6$1 digitaldaemon.com...
 I guess if it's an operator "in" makes sense.
 But if it's a method "contains" is better...
 if ( f.Contains ( "bar" ) ) ...

 And personally, I prefer methods rather than bogging a language down


 operators. Especially when the operation is not likely to be used in




 larger
 expression, as boolean expressions seldom are.

In general I agree, but I think "in" will be widely used, especially if



 can overload it.

 I vote for opIn, btw. (Call it what it is)

 In article <buktne$217e$1 digitaldaemon.com>, C says...
Very cool!

"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }






Jan 21 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
The Lone Haranguer wrote:
 If it's not a mathematical operation it shouldn't be an operator.
 

Why? Besides, set theory has an 'in' operator. I don't think the symbol it uses is a part of normal ASCII, though. -- andy
Jan 21 2004
prev sibling next sibling parent reply "Robert" <no spam.ne.jp> writes:
I don't agree.
Indeed, it looks nice, but that's all.
I will be satisfied if there is 'member' method as Lisp and Prolog.

if(f.member("bar")) { }


"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bukqnu$1sio$1 digitaldaemon.com...
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }

Jan 21 2004
parent "Robert" <no spam.ne.jp> writes:
"Patrick Down" <Patrick_member pathlink.com> wrote in message
news:bun2pp$2e60$1 digitaldaemon.com...
 'in' is also used for associative arrays.  Read the documentation:
 http://www.digitalmars.com/d/arrays.html

Hmm. I've forgot it! Indeed, 'opContains' should be supported. I agree.
Jan 21 2004
prev sibling next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
The main reason for this is to be able to completely
emulate the fuctionality of associative arrays.

In article <bukqnu$1sio$1 digitaldaemon.com>, Patrick Down says...
A an operator overload for 'in' would be nice.

class Foo
{
bool opContains(char[]) {}
}

Foo f;

if("bar" in f) { }

Jan 21 2004
prev sibling parent reply Stephan Wienczny <wienczny web.de> writes:
Patrick Down wrote:
 A an operator overload for 'in' would be nice.
 
 class Foo
 {
 bool opContains(char[]) {}
 }
 
 Foo f;
 
 if("bar" in f) { }
 
 

I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember: in {} out(result){} body{} Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be ' ' if ("bar" f) {} What do you think
Jan 21 2004
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <bumklq$1nfm$1 digitaldaemon.com>, Stephan Wienczny says...
Patrick Down wrote:
 A an operator overload for 'in' would be nice.
 
 class Foo
 {
 bool opContains(char[]) {}
 }
 
 Foo f;
 
 if("bar" in f) { }
 
 

I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember:

'in' is also used for associative arrays. Read the documentation: http://www.digitalmars.com/d/arrays.html
in {}
out(result){}
body{}

Such an operator would be nice, but it should use another identifier.
Looking at my keyboard one solution could be ' '

if ("bar"   f) {}

What do you think

Jan 21 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Stephan Wienczny" <wienczny web.de> wrote in message
news:bumklq$1nfm$1 digitaldaemon.com...
 Patrick Down wrote:
 A an operator overload for 'in' would be nice.

 class Foo
 {
 bool opContains(char[]) {}
 }

 Foo f;

 if("bar" in f) { }

I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember: in {} out(result){} body{}

Even if that is so - and I have to question how it is already managed for ass arrays if it's too hard - I think it's worth it.
 Such an operator would be nice, but it should use another identifier.
 Looking at my keyboard one solution could be ' '

 if ("bar"   f) {}

 What do you think

Not much
Jan 21 2004