"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdof$2o8r$1@digitaldaemon.com...
> "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.

Thanks.  I guess I had a brain glitch.  :-(

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a7tl44$2s36$1@digitaldaemon.com...

> Assignment in math is not a standard operation,
> they use let? (let a = 10)...
> Also Pascal uses := for assignment and = for
> comparison.

Hm, I've always thought that := is a standard math assignment? At least MathCAD uses it for that purpose...

> === 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.

Yes, right.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tds3$2o9l$1@digitaldaemon.com...
>
> "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.

So it's already been decided then?   Well what the hell are we discussing it for?

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

Implementation detail.  It will work.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdul$2oan$1@digitaldaemon.com...

> I haven't _ever_ confused == with ===.

Good for you.  That will help all the people who do confuse them.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a7ungk$bp0$1@digitaldaemon.com...

> > Seriously speaking, since === will be used on arrays, I don't see why it can't be used on objects as well.
>
> So it's already been decided then?   Well what the hell are we discussing
it
> for?

Walter decided to use it for arrays. I thought we were discussing, how to apply it to 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...
>
> Implementation detail.  It will work.

... by banning pointers to references (because & won't work on references
as expected).

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a7unkc$bpm$1@digitaldaemon.com...

> Good for you.  That will help all the people who do confuse them.

And who does? I've never seen === in any language other than JavaScript, and I've never heard of any JS programmer who confuses == with ===.

Pavel Minayev wrote:

> "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.

And more fun ...

        Sheep aSheep = new Sheep();
        Sheep dolly = aSheep.clone();

:-)

C       2002/3/28

Walter wrote:
> "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.

If I understand correctly, you mean the compiler would treat all these the same way:

  if (b[] == a)
  if (b[] == a[])
  if (b[] == a[0..a.length])

which sounds good to me.  As a D end-user, that's what I would have expected I guess.

So I'm still scratching my head over this, and curious as to why it's a problem.  Not so much to press the point of advocating that particular syntax, but mainly because it's kind if enlightening to be observing the beginning of a new language and pick up little tidbits here and there from Walter as to why things are or aren't workable for a compiler.
	
	Barry

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdul$2oan$1@digitaldaemon.com...
> "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.

I don't think this is correct.

The only time I can imagine caring if Object a refers to the same thing as Object b is when I'm writing the "element delete" function for a singly-linked list. And with with decent collection class libraries, I shouldn't be needing to do that.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7sdik$270c$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a7s4ag$223b$1@digitaldaemon.com...
> > "Roberto Mariottini" <rmariottini@lycosmail.com> wrote in message news:a7rutn$1va1$1@digitaldaemon.com...
> > > 1 - Waht about assignment?
> > >
> > >     Object1 a;
> > >     Object1 b;
> > >
> > >     a = b;  // by-reference assignment
> > >     ????    // by-value assignment?
> >
> > I was thinking of a dup() method in Object.
> The default version (straight copy all members) will be generated
> automatically?

Yes.