Instead of

class A
	{
	    int opCmp(Object o)
	    {
       assert(0);	// comparison makes no sense
       return 0;
	    }
	}

perhaps add syntax like:

class A {
  int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
}

Jeroen van Bemmel wrote:

> Instead of
> 
> class A
> 	{
> 	    int opCmp(Object o)
> 	    {
>        assert(0);	// comparison makes no sense
>        return 0;
> 	    }
> 	}
> 
> perhaps add syntax like:
> 
> class A {
>   int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
> } 

Seems like too small of a difference to add a keyword.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

On Tue, 8 Jun 2004 08:07:28 +0200, Jeroen van Bemmel wrote:

> Instead of
> 
> class A
> 	{
> 	    int opCmp(Object o)
> 	    {
>        assert(0);	// comparison makes no sense
>        return 0;
> 	    }
> 	}
> 
> perhaps add syntax like:
> 
> class A {
>   int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
> }

So it becomes a compile-time error rather than a run-time error, right?

-- 
Derek
Melbourne, Australia
8/Jun/04 4:27:22 PM

How about this:

class A
 {
private:
     int opCmp(Object o)
     {
        assert(0); // comparison makes no sense
        return 0;
     }
};


-- 
Jan-Eric Duden
"J C Calvarese" <jcc7@cox.net> wrote in message
news:ca3m7u$2tbk$2@digitaldaemon.com...
> Jeroen van Bemmel wrote:
>
> > Instead of
> >
> > class A
> > {
> >     int opCmp(Object o)
> >     {
> >        assert(0); // comparison makes no sense
> >        return 0;
> >     }
> > }
> >
> > perhaps add syntax like:
> >
> > class A {
> >   int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
> > }
>
> Seems like too small of a difference to add a keyword.
>
> -- 
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/

In article <ca3l2n$2rv1$1@digitaldaemon.com>, Jeroen van Bemmel says...

>perhaps add syntax like:
>
>class A {
>  int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
>}

Actually, this is a pretty neat idea. In general, you might want to say that a class B which subclasses class A might want to *remove* features which A offered (as opposed to adding them, which is the normal thing to do). Another example might be: A has a function serialize(), but B (which subclasses A) does not, so you want to somehow forbid b.serialize(). The normal way this is done is to override the disallowed function with a function which throws an exeption or asserts, but it would be nice to have another way.

This isn't just syntactic sugar though. There are real compiler/performance benefits, in a manner similar to final. For example, given the situations described above, a compiler COULD detect:

>       b.serialize()

or

>       a < b

and give you a COMPILE-TIME error instead of a run-time error. That's not syntactic sugar, that's a feature.

Basically, your "disallowed" keyword would mean: "We dont' implement this function, and if you try to call it, we don't want you to be forwarded to the superclass function either".

Probably a nightmare to implement though.

Arcane Jill

"Jeroen van Bemmel" <someone@somewhere.com> wrote in message news:ca3l2n$2rv1$1@digitaldaemon.com...
> Instead of
>
> class A
> {
>     int opCmp(Object o)
>     {
>        assert(0); // comparison makes no sense
>        return 0;
>     }
> }
>
> perhaps add syntax like:
>
> class A {
>   int opCmp( Object o ) disallowed; // or "fail" or "error" or ...
> }

I thinks the problem would easilly go away if Object didn't have opCmp, then it would be a compile time error!

I really think it is a bit strange that when i define a class there is automatically a opCmp defined doing address comparison.

I write
class A{}

A a,b; a=new A(); b=new A();

and a<b and a==b are not compile time errors, but a code doing something else. Smels!

In article <ca3osv$11f$1@digitaldaemon.com>, Jan-Eric Duden says...
>
>How about this:
>
>class A
> {
>private:
>     int opCmp(Object o)
>     {
>        assert(0); // comparison makes no sense
>        return 0;
>     }

Der. You're right. I should have thought of that!
Jill

private isn't *that* private though

I could call it accidentally from within my class or within the module even!


In article <ca3qiv$4lb$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ca3osv$11f$1@digitaldaemon.com>, Jan-Eric Duden says...
>>
>>How about this:
>>
>>class A
>> {
>>private:
>>     int opCmp(Object o)
>>     {
>>        assert(0); // comparison makes no sense
>>        return 0;
>>     }
>
>Der. You're right. I should have thought of that!
>Jill
>
>

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca3qiv$4lb$1@digitaldaemon.com...
> In article <ca3osv$11f$1@digitaldaemon.com>, Jan-Eric Duden says...
> >
> >How about this:
> >
> >class A
> > {
> >private:
> >     int opCmp(Object o)
> >     {
> >        assert(0); // comparison makes no sense
> >        return 0;
> >     }
>
> Der. You're right. I should have thought of that!
> Jill
>

But this isn't the same. This way we have a function that
asserts, but the way Jeroen sugested it would
be the same as if that function didn't exist.

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:ca3v5u$fcp$1@digitaldaemon.com...
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca3qiv$4lb$1@digitaldaemon.com...
> > In article <ca3osv$11f$1@digitaldaemon.com>, Jan-Eric Duden says...
> > >
> > >How about this:
> > >
> > >class A
> > > {
> > >private:
> > >     int opCmp(Object o)
> > >     {
> > >        assert(0); // comparison makes no sense
> > >        return 0;
> > >     }
> >
> > Der. You're right. I should have thought of that!
> > Jill
> >
>
> But this isn't the same. This way we have a function that
> asserts, but the way Jeroen sugested it would
> be the same as if that function didn't exist.
>

I meant to say that they are both compile time errors,
but assert lets you call a function where "disallowed"
doesn't.