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