Derek wrote:
> Norbert,
> are you saying that its okay for this type of thing to be a run-time error
> but not a compile-time error? Isn't that what the request is really about?
> That is, let's change this technique from a run-time test to one that is
> detected at compile-time instead.
> 
> Let's say that somebody has written a Real Neat Class (RNC) that has a
> sorting method in it. Now I wish to create a new class based on this but
> sorting is not really sensible for it, so I wish to prevent the sort method
> from *ever* being used. Yes, I could write a sort method that caused a
> run-time effect (eg. throw an exception), or if we had a disable facility,
> to tell the compiler that I'm explictly disallowing any code to call the
> parent's sort method.
> 
> I think that in principle, compile-time error detection is better than
> run-time detection.
> 

Maybe using the *deprecate* attribute? That's compile time.


-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/

In article <ca7i8c$488$1@digitaldaemon.com>, Ivan Senji says...
>
>"Andy Friesen" <andy@ikagames.com> wrote in message news:ca7gof$22p$1@digitaldaemon.com...
>> Derek wrote:
>>
>> > are you saying that its okay for this type of thing to be a run-time
>error
>> > but not a compile-time error? Isn't that what the request is really
>about?
>> > That is, let's change this technique from a run-time test to one that is detected at compile-time instead.
>> >
>> > Let's say that somebody has written a Real Neat Class (RNC) that has a sorting method in it. Now I wish to create a new class based on this but sorting is not really sensible for it, so I wish to prevent the sort
>method
>> > from *ever* being used. Yes, I could write a sort method that caused a run-time effect (eg. throw an exception), or if we had a disable
>facility,
>> > to tell the compiler that I'm explictly disallowing any code to call the parent's sort method.
>>
>> Since your RealNeatSubclass is-a RealNeatClass, there's a problem if it be used any place a RNC is needed.  Further, compile-time checking for this sort of thing will be incomplete at best.
>>
>> RNC rnc = new RealNeatSubclass();
>> if (rnc < otherRnc) // the compiler can't help you here
>>
>> Polymorphism can't be used to subtract behaviours from a class.

I agree with Ivan Senji here; and even if it was possible, I think it would be unwise: in all OO languages I know, a derived class adds functionality to his base class. If one writes a generic algorithm based on functionalities (or a given functionality) of class A, I think it would be undesirable that algoritm to fail (or to be unavailable) for a class B derived from A, because B is-a A.

If a given functionality of class A makes no sense for class B, I think it could be better to derive class B from a super class of A that does not have the non-sense functionality.

>>
>> (this is why Object mustn't define opCmp or opEquals, incidently)

I think I see the point: if Object defines opCmp or opEquals and object is the default super class, then (if what I just said holds) all classes will have these operators defined. So, what if, for a given class, opCmp or opEquals makes no sense?

But I think allowing the de-powering of a super class is not the right answer; I think it would be better if D had a SuperObject class (as super class of Object). That SuperObject class should not have any specific functionality at all (no variables, functions or operators defined) and all classes that don't want some of the functionality of Object should be derived from SuperObject rather than from Object. Object could continue to be the default base class for all the classes that doesn't declare a base class explicitly, in order not to break actual code (and because I think most classes will need Object's functionality).

This would allow building a class with less functionality than Object.

>
>SORRY! SORRY! SORRY! I read must :)
>I'am glad that there is atleast one person to agree with me on this.
>Great!
>
>>   -- andy
>
>

Marcello Gnani

"Marcello Gnani" <marcello_gnani@tiscali.it> wrote in message news:ca9mge$ba0$1@digitaldaemon.com...
> In article <ca7i8c$488$1@digitaldaemon.com>, Ivan Senji says...
> >
> >"Andy Friesen" <andy@ikagames.com> wrote in message news:ca7gof$22p$1@digitaldaemon.com...
> >> Derek wrote:
> >>
> >> > are you saying that its okay for this type of thing to be a run-time
> >error
> >> > but not a compile-time error? Isn't that what the request is really
> >about?
> >> > That is, let's change this technique from a run-time test to one that
is
> >> > detected at compile-time instead.
> >> >
> >> > Let's say that somebody has written a Real Neat Class (RNC) that has
a
> >> > sorting method in it. Now I wish to create a new class based on this
but
> >> > sorting is not really sensible for it, so I wish to prevent the sort
> >method
> >> > from *ever* being used. Yes, I could write a sort method that caused
a
> >> > run-time effect (eg. throw an exception), or if we had a disable
> >facility,
> >> > to tell the compiler that I'm explictly disallowing any code to call
the
> >> > parent's sort method.
> >>
> >> Since your RealNeatSubclass is-a RealNeatClass, there's a problem if it be used any place a RNC is needed.  Further, compile-time checking for this sort of thing will be incomplete at best.
> >>
> >> RNC rnc = new RealNeatSubclass();
> >> if (rnc < otherRnc) // the compiler can't help you here
> >>
> >> Polymorphism can't be used to subtract behaviours from a class.
>
> I agree with Ivan Senji here; and even if it was possible, I think it
would be
> unwise: in all OO languages I know, a derived class adds functionality to
his
> base class. If one writes a generic algorithm based on functionalities (or
a
> given functionality) of class A, I think it would be undesirable that
algoritm
> to fail (or to be unavailable) for a class B derived from A, because B
is-a A.
>
> If a given functionality of class A makes no sense for class B, I think it
could
> be better to derive class B from a super class of A that does not have the non-sense functionality.
>
> >>
> >> (this is why Object mustn't define opCmp or opEquals, incidently)
>
> I think I see the point: if Object defines opCmp or opEquals and object is
the
> default super class, then (if what I just said holds) all classes will
have
> these operators defined. So, what if, for a given class, opCmp or opEquals
makes
> no sense?

That is exactly what is the problem.

> But I think allowing the de-powering of a super class is not the right
answer; I

I at first thought why not, it seamed like a god idea to allow it but now i know it would be bad.

> think it would be better if D had a SuperObject class (as super class of Object). That SuperObject class should not have any specific functionality
at

Or even simpler just remove these two operators from object, and have a standard mixin that defines them so everyone has a choice to have them or not.

> all (no variables, functions or operators defined) and all classes that
don't
> want some of the functionality of Object should be derived from
SuperObject
> rather than from Object. Object could continue to be the default base
class for
> all the classes that doesn't declare a base class explicitly, in order not
to
> break actual code (and because I think most classes will need Object's
> functionality).
>
> This would allow building a class with less functionality than Object.
>
> >
> >SORRY! SORRY! SORRY! I read must :)
> >I'am glad that there is atleast one person to agree with me on this.
> >Great!
> >
> >>   -- andy
> >
> >
>
> Marcello Gnani

Hi Norbert,

Theoretically you are right. The compiler won't be able to detect all cases of infringement at compile time, so it should still generate the assert(0) (and/or throw an exception) code that is currently suggested in the documentation.

However, my suggestion does not change the design of the code. It was already designed to effectively disallow the method in the subclass, all I do is make it explicit. Whether or not this feature should be recommended for general use, perhaps "avoid when possible". But in those cases where you would otherwise put 'assert(0); throw exception', well why not? It's syntactic sugar, in other words, shorthand for the code that's there now.


"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:ca6q4t$1vu1$2@digitaldaemon.com...
> Arcane Jill wrote:
>
>> 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 goes completely contrary to all concepts of OO: Polymorphism and inheritance say that a subclass has all capabilities of the parent class.
>
> If you want to disallow a feature in a subclass, that is either a sign of
> lazyness of bad design. Sometimes, throwing an assert(0) may be feasible,
> but the compiler will never be able to handle that kind of "disallowing"
> at
> compile-time.
>
>