"Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns91DE7FB166B28juarezcom@63.105.9.61...
> I'm curious now ... what about array slicing threw a wrench in the works?

a
a[]
a[0..a.length]

all semantically mean the same thing as rvalues. Hence, no way to distinguish. As lvalues, I *can* distinguish them.

I would rather just write "&x == &y".  It's explicit.  It's easy.

=== is too easy to confuse with == which is already too easy to confuse with =.

Sean

> "x === y" can become the meaning of "&x == &y" in general, so this is not confusing too...
>
> Imi

Yeah, dup is so FORTH.  ;)

Sean

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a7t3cs$2it9$1@digitaldaemon.com...

> > I was thinking of a dup() method in Object.
>
> name it clone()
>
> dup is somewhat.....somewhat.....
>
> clone() is better, I think ;-)
>
>
> Imi

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a7t3cs$2it9$1@digitaldaemon.com...

> clone() is better, I think ;-)

And it is a standard de facto.

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4ch$2jfd$3@digitaldaemon.com...

> Does this imply that equality comparisons will be supported on the
contents
> of "strings", but not greater than or less than?  That seems like a bad idea, as such comparisons are often quite usefull.

From the very first post in the thread:

"Since <, <=, >, >= make little sense on dynamic array references, those are by value."

So you will be able to perform comparisons on strings and other arrays.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a7t5g6$2k4k$1@digitaldaemon.com...

> I would rather just write "&x == &y".  It's explicit.  It's easy.
>
> === is too easy to confuse with == which is already too easy to confuse
with
> =.

All C/C++/D programmers should have natural immunity to confusing = with ==, and thus == and === won't be confused either =)

Seriously speaking, since === will be used on arrays, I don't see why it can't be used on objects as well.

Also, & is an "address of" operator, so &x will be of type Object*, and you will in fact compare addresses of references...

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a7t1n7$2i4a$1@digitaldaemon.com...

> Comparing references is so frequently a mistake, that I'm inclined to want it to be difficult.  If you simply must know, maybe do it by casting the object or array to void* (that .pointer property was also a good idea) and compare those.

Comparing references is, in fact, more frequent than comparing values, for objects.

> Dealing with = vs == is enough, thank you.  Please don't add any such operators as === and !==.

They are already in JavaScript, and I'd say they work rather good. I haven't _ever_ confused == with ===.

"Walter" <walter@digitalmars.com> wrote in message news:a7r7ok$1ing$2@digitaldaemon.com...
> I've been reading all the messages on string comparisons, and propose the following:
>
> Since <, <=, >, >= make little sense on dynamic array references, those
are
> by value. Introduce two new operators, === and !==, to do a by-value comparison for arrays. Similarly, for class objects, == and != will
compare
> the references, and === and !== will call the equals() function in the
> Object base class.
>
>

I love it!
I would like it vice versa, so == is by value in all situations
(base type, array, object, struct), and === by reference, but
that's nitpicking and it would break a lot of existing code.

I read your posts on dup() and equals().
Basically you are doing a lot of what I was hoping for with my
request for standard interfaces for operators in the thread
"Operator overloading, a way to make everybody happy?", but
instead of using interfaces, you are placing the functions
directly in Object. It doesn't really matter, it's the end
result that counts! This way is probably a lot more efficient?

Let me get it straight:

MyObject a = new MyObject, b = new MyObject;
...
if (a === b)      // will translate to if (a.equals (b)) ?
if (a !== b)      // will translate to if (! a.equals (b)) ?
if (a > b)        // will translate to if (a.cmp (b) > 0) ?
if (a >= b)       // will translate to if (a.cmp (b) >= 0) ?
if (a < b)        // will translate to if (a.cmp (b) < 0) ?
if (a <= b)       // will translate to if (a.cmp (b) <= 0) ?
a = b             // will translate to a.dup (b) ?

If this is true, I'm sold! I would love that!

Now building on this you might implement addition, subtraction, multiplication and division in much the same way. The default implementation of add() etc in object would just throw an OperatorNotSupported exception, but descendant classes could override them to do some serious work! Ofcourse, functionality to check what operators a class supports would also be very welcome:

if (a.supportsop (Operator.PLUS))  // ....

Sorry for grabbing the hand as soon as you give me a
finger, but I love the concept of operator overloading,
and this would make it fairly transparent to implement.
Also, operator overloading haters could always directly
call the normal functions.

Thanks Walter, great!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdm2$2o86$1@digitaldaemon.com...
> "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a7t3cs$2it9$1@digitaldaemon.com...
>
> > clone() is better, I think ;-)
>
> And it is a standard de facto.
>
>

Agreed.

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Richard Krehbiel" <rich@kastle.com> wrote in message
news:a7t1n7$2i4a$1@digitaldaemon.com...
<SNIP>
>
> Dealing with = vs == is enough, thank you.  Please don't add any such operators as === and !==.
>
> --
> Richard Krehbiel, Arlington, VA, USA
> rich@kastle.com (work) or krehbiel3@comcast.net  (personal)
>
>

The reason == and = are often mistaken (IMHO)
is that for lots of people = means equals.
Certainly it usually means that in math... :)
Assignment in math is not a standard operation,
they use let? (let a = 10)...
Also Pascal uses := for assignment and = for
comparison.
=== on the other hand is not a standard symbol
in math and people already (must) know that there
is a difference between = and ==, so learning
=== should be easy.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail