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 :)

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 :)

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

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/

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

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

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.

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

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

"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 :)