www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - more on operators

reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In the latest release Walter fixed one thing with operators that was
bugging me a lot. But there is also another one:

Why must object have opCmp and opEquals?

If this is a feature it is a bug cousing one, and now i am
going to give an example of this. This happened to me :)

I wrote a simple and stupid set template and a class A

class A
{
    int opEguals(A obj)
    {
        //comapre objects
    }
}

Internally my set template uses opEquals. And everything works
fine except that it doesn't work at all! My set template didn't work
and i couldn't find a problem in it.

After some (too much!) time i finally figured out that the problem =
wasn't
in set template but in the class A. I wrote opEguals instead of
opEquals and there was no error message from the compiler.

Object class has methods
opEquals wich does "a=3D=3D=3Db" or "a is b" and
opCmp which does &a-&b (if i remember corectly)

I find it confusing and bad. We have a special operator for identity
comparing, and problems are going to start happening when=20
some people start writing code that depends on =3D=3D being equal to =
=3D=3D=3D

Bot these constructs can be easilly expressed in the language we have,
identity even has its own operator, and it isn't that much trouble=20
do calculate the distance between adresses of instances.

Conclusion: There shouldn't be a default implementation for these two
operators. It prevents template code being writen that depends
on these two operators to be meaningfully implemented.

Is there anyone or any feature of D that is using this?=20
I decided not to give up on this isue this time, atleast until i get a=20
good answer, in wich case i will admit i was wrong. But please comment=20
on this.

Features like this one, that hide bugs shouldn't be welcome in a=20
language as D :)
Jun 08 2004
parent reply "Walter" <newshound digitalmars.com> writes:
Please don't post in html format. It makes it really hard to intersperse
replies with the original text. I'll repost in plaintext...

--------------------------------------------------------------
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:ca52di$2d4t$2 digitaldaemon.com...
In the latest release Walter fixed one thing with operators that was
bugging me a lot. But there is also another one:

Why must object have opCmp and opEquals?

If this is a feature it is a bug cousing one, and now i am
going to give an example of this. This happened to me :)

I wrote a simple and stupid set template and a class A

class A
{
    int opEguals(A obj)
    {
        //comapre objects
    }
}

Internally my set template uses opEquals. And everything works
fine except that it doesn't work at all! My set template didn't work
and i couldn't find a problem in it.

After some (too much!) time i finally figured out that the problem wasn't
in set template but in the class A. I wrote opEguals instead of
opEquals and there was no error message from the compiler.

Object class has methods
opEquals wich does "a===b" or "a is b" and
opCmp which does &a-&b (if i remember corectly)

I find it confusing and bad. We have a special operator for identity
comparing, and problems are going to start happening when
some people start writing code that depends on == being equal to ===

Bot these constructs can be easilly expressed in the language we have,
identity even has its own operator, and it isn't that much trouble
do calculate the distance between adresses of instances.

Conclusion: There shouldn't be a default implementation for these two
operators. It prevents template code being writen that depends
on these two operators to be meaningfully implemented.

Is there anyone or any feature of D that is using this?
I decided not to give up on this isue this time, atleast until i get a
good answer, in wich case i will admit i was wrong. But please comment
on this.

Features like this one, that hide bugs shouldn't be welcome in a
language as D :)
Jun 08 2004
parent reply "Walter" <newshound digitalmars.com> writes:
 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:ca52di$2d4t$2 digitaldaemon.com...
 In the latest release Walter fixed one thing with operators that was
 bugging me a lot. But there is also another one:

 Why must object have opCmp and opEquals?


Because ordering (opCmp) and identity (opEquals) are different properties of
an object. An object may have an identity property, but have no ordering.
Furthermore, determining an ordering is frequently a far more expensive
operation than determining identity.


 If this is a feature it is a bug cousing one, and now i am
 going to give an example of this. This happened to me :)

 I wrote a simple and stupid set template and a class A

 class A
 {
     int opEguals(A obj)
     {
         //comapre objects
     }
 }

 Internally my set template uses opEquals. And everything works
 fine except that it doesn't work at all! My set template didn't work
 and i couldn't find a problem in it.

 After some (too much!) time i finally figured out that the problem wasn't
 in set template but in the class A. I wrote opEguals instead of
 opEquals and there was no error message from the compiler.


In general in programming, typos are a perrenial problem.


 Object class has methods
 opEquals wich does "a===b" or "a is b" and
 opCmp which does &a-&b (if i remember corectly)
 I find it confusing and bad. We have a special operator for identity
 comparing, and problems are going to start happening when
 some people start writing code that depends on == being equal to ===

 Bot these constructs can be easilly expressed in the language we have,
 identity even has its own operator, and it isn't that much trouble
 do calculate the distance between adresses of instances.

 Conclusion: There shouldn't be a default implementation for these two
 operators. It prevents template code being writen that depends
 on these two operators to be meaningfully implemented.

 Is there anyone or any feature of D that is using this?
 I decided not to give up on this isue this time, atleast until i get a
 good answer, in wich case i will admit i was wrong. But please comment
 on this.

 Features like this one, that hide bugs shouldn't be welcome in a
 language as D :)


I've been considering replacing the bodies of Object.opEquals and opCmp with
assert(0).
Jun 08 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 8 Jun 2004 15:31:16 -0700, Walter <newshound digitalmars.com> 
wrote:

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:ca52di$2d4t$2 digitaldaemon.com...
 In the latest release Walter fixed one thing with operators that was
 bugging me a lot. But there is also another one:

 Why must object have opCmp and opEquals?


 Because ordering (opCmp) and identity (opEquals) are different 
 properties of
 an object. An object may have an identity property, but have no ordering.
 Furthermore, determining an ordering is frequently a far more expensive
 operation than determining identity.


 If this is a feature it is a bug cousing one, and now i am
 going to give an example of this. This happened to me :)

 I wrote a simple and stupid set template and a class A

 class A
 {
     int opEguals(A obj)
     {
         //comapre objects
     }
 }

 Internally my set template uses opEquals. And everything works
 fine except that it doesn't work at all! My set template didn't work
 and i couldn't find a problem in it.

 After some (too much!) time i finally figured out that the problem 
 wasn't
 in set template but in the class A. I wrote opEguals instead of
 opEquals and there was no error message from the compiler.


 In general in programming, typos are a perrenial problem.


You could avoid this one if there was an operator keyword, i.e.

  class A
  {
      operator int opEguals(A obj)
      {
          //comapre objects
      }
  }

compiler could throw an error, 'no such operator opEguals'

Regan.


 Object class has methods
 opEquals wich does "a===b" or "a is b" and
 opCmp which does &a-&b (if i remember corectly)
 I find it confusing and bad. We have a special operator for identity
 comparing, and problems are going to start happening when
 some people start writing code that depends on == being equal to ===

 Bot these constructs can be easilly expressed in the language we have,
 identity even has its own operator, and it isn't that much trouble
 do calculate the distance between adresses of instances.

 Conclusion: There shouldn't be a default implementation for these two
 operators. It prevents template code being writen that depends
 on these two operators to be meaningfully implemented.

 Is there anyone or any feature of D that is using this?
 I decided not to give up on this isue this time, atleast until i get a
 good answer, in wich case i will admit i was wrong. But please comment
 on this.

 Features like this one, that hide bugs shouldn't be welcome in a
 language as D :)


 I've been considering replacing the bodies of Object.opEquals and opCmp 
 with
 assert(0).




-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 08 2004
prev sibling next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:ca5f08$1eo$1 digitaldaemon.com...

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:ca52di$2d4t$2 digitaldaemon.com...
 In the latest release Walter fixed one thing with operators that was
 bugging me a lot. But there is also another one:

 Why must object have opCmp and opEquals?


 Because ordering (opCmp) and identity (opEquals) are different properties


of

 an object. An object may have an identity property, but have no ordering.
 Furthermore, determining an ordering is frequently a far more expensive
 operation than determining identity.


First sorry about html it was an acident :)

HM! This doesn't really answer my questions. I know they are different
properties of an object, and that some object may not even have them,
BUT in D every object has default values for these two operators, and
these defaults don't even do anything smart, that can't easilly be done
in the language.


 If this is a feature it is a bug cousing one, and now i am
 going to give an example of this. This happened to me :)

 I wrote a simple and stupid set template and a class A

 class A
 {
     int opEguals(A obj)
     {
         //comapre objects
     }
 }

 Internally my set template uses opEquals. And everything works
 fine except that it doesn't work at all! My set template didn't work
 and i couldn't find a problem in it.

 After some (too much!) time i finally figured out that the problem




wasn't

 in set template but in the class A. I wrote opEguals instead of
 opEquals and there was no error message from the compiler.


 In general in programming, typos are a perrenial problem.


But if these operators were not in object, then this would have been
a compile time error: "no opEquals for type A" or something like that.

I wonder if anyone relies on this feature? Maybe the associative array
code?


 Object class has methods
 opEquals wich does "a===b" or "a is b" and
 opCmp which does &a-&b (if i remember corectly)
 I find it confusing and bad. We have a special operator for identity
 comparing, and problems are going to start happening when
 some people start writing code that depends on == being equal to ===

 Bot these constructs can be easilly expressed in the language we have,
 identity even has its own operator, and it isn't that much trouble
 do calculate the distance between adresses of instances.

 Conclusion: There shouldn't be a default implementation for these two
 operators. It prevents template code being writen that depends
 on these two operators to be meaningfully implemented.

 Is there anyone or any feature of D that is using this?
 I decided not to give up on this isue this time, atleast until i get a
 good answer, in wich case i will admit i was wrong. But please comment
 on this.

 Features like this one, that hide bugs shouldn't be welcome in a
 language as D :)


 I've been considering replacing the bodies of Object.opEquals and opCmp


with

 assert(0).


But again: why are they needed in the first place(you have just said that
they will
do nothing). They will still cause a runtime error were it could have
easilly been
a compile time.
Jun 08 2004
parent "Walter" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:ca6b00$19po$1 digitaldaemon.com...

 But again: why are they needed in the first place(you have just said that
 they will
 do nothing). They will still cause a runtime error were it could have
 easilly been
 a compile time.


They are there to reserve a spot in the vtbl[] so that all classes can be
sorted, work in associative arrays, etc.
Jun 27 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:ca5f08$1eo$1 digitaldaemon.com...

 "Ivan Senji" <ivan.senji public.srce.hr> wrote in message
 news:ca52di$2d4t$2 digitaldaemon.com...
 In the latest release Walter fixed one thing with operators that was
 bugging me a lot. But there is also another one:

 Why must object have opCmp and opEquals?


 Because ordering (opCmp) and identity (opEquals) are different properties


of

 an object. An object may have an identity property, but have no ordering.
 Furthermore, determining an ordering is frequently a far more expensive
 operation than determining identity.


Why not have a standard mixin that implements these two, but not forse it
on everyones object?


 If this is a feature it is a bug cousing one, and now i am
 going to give an example of this. This happened to me :)

 I wrote a simple and stupid set template and a class A

 class A
 {
     int opEguals(A obj)
     {
         //comapre objects
     }
 }

 Internally my set template uses opEquals. And everything works
 fine except that it doesn't work at all! My set template didn't work
 and i couldn't find a problem in it.

 After some (too much!) time i finally figured out that the problem




wasn't

 in set template but in the class A. I wrote opEguals instead of
 opEquals and there was no error message from the compiler.


 In general in programming, typos are a perrenial problem.


 Object class has methods
 opEquals wich does "a===b" or "a is b" and
 opCmp which does &a-&b (if i remember corectly)
 I find it confusing and bad. We have a special operator for identity
 comparing, and problems are going to start happening when
 some people start writing code that depends on == being equal to ===

 Bot these constructs can be easilly expressed in the language we have,
 identity even has its own operator, and it isn't that much trouble
 do calculate the distance between adresses of instances.

 Conclusion: There shouldn't be a default implementation for these two
 operators. It prevents template code being writen that depends
 on these two operators to be meaningfully implemented.

 Is there anyone or any feature of D that is using this?
 I decided not to give up on this isue this time, atleast until i get a
 good answer, in wich case i will admit i was wrong. But please comment
 on this.

 Features like this one, that hide bugs shouldn't be welcome in a
 language as D :)


 I've been considering replacing the bodies of Object.opEquals and opCmp


with

 assert(0).
Jun 09 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

<snip>

 I've been considering replacing the bodies of Object.opEquals and opCmp with
 assert(0).


Why not get rid of Object.opCmp altogether?

Object.opEquals is more debatable in this respect.  It's been pretty 
much talked to death starting at
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/3387

Of course, there'll always be tricky issues as people try to define 
self-specific opEquals methods.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jun 10 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:ca9qn8$hsc$1 digitaldaemon.com...

 Walter wrote:

 <snip>

 I've been considering replacing the bodies of Object.opEquals and opCmp




with

 assert(0).


 Why not get rid of Object.opCmp altogether?


It's needed for associative arrays to work.
Jun 27 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cboag4$2lg7$2 digitaldaemon.com...

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:ca9qn8$hsc$1 digitaldaemon.com...

 Walter wrote:

 <snip>

 I've been considering replacing the bodies of Object.opEquals and






opCmp

 with

 assert(0).


 Why not get rid of Object.opCmp altogether?


 It's needed for associative arrays to work.


Thanks! I appreciate the answer.

Although i would still prefer if
class A{}
int[A] associative;

Was a nice compile time error:
"A" cannot be an index to associative array (missing opCmp and opEquals!)

fixed by:
class A{    mixin stdopCmpAndopEquals;  }

You said that your have been considering to replace the bodies
of these two with assert(0), making it a runtime error where
it could be a compile time.

But no language is perfect :)
and for now D is close enough for me :)
Jun 28 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:
<snip>

 Although i would still prefer if
 class A{}
 int[A] associative;
 
 Was a nice compile time error:
 "A" cannot be an index to associative array (missing opCmp and opEquals!)


<snip>

As has been said already, AAs ought not to require that the key type be 
comparable.

See also my post half an hour ago on d.D:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jul 05 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:ccbf5v$1pjq$1 digitaldaemon.com...

 Ivan Senji wrote:
 <snip>

 Although i would still prefer if
 class A{}
 int[A] associative;

 Was a nice compile time error:
 "A" cannot be an index to associative array (missing opCmp and




opEquals!)

 <snip>

 As has been said already, AAs ought not to require that the key type be
 comparable.

 See also my post half an hour ago on d.D:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406


What should the associative array require then? The thing i was complaining
about isn't the AAs but opEquals and opCmp being in object!


 Stewart.

 --
 My e-mail is valid but not my primary mailbox, aside from its being the
 unfortunate victim of intensive mail-bombing at the moment.  Please keep
 replies on the 'group where everyone may benefit.
Jul 05 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Ivan Senji wrote:

<snip>

 See also my post half an hour ago on d.D: 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5406


 
 What should the associative array require then?


Only an opEquals.  Oh yes, and a toHash.


 The thing i was complaining about isn't the AAs but opEquals and 
 opCmp being in object!


I think we all understand this.  The point being that the AA 
implementation is a blocker for tidying these things up.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jul 05 2004