Forums

by JADE Kid - Ray Hidayat >> Fri, 12 Jan 2001 0:28:58 GMT

Sometimes I have a method that I want to put code in, but I don't want any method to run the method by mistake. It is supposed to be reimplemented in the subclasses, but they will inherit behaviour from this method. Sort of like Partial Abstract-ness. They are reimplemented in concrete subclasses and its behaviour is inherited.

Is this possible, or does this feature need to be added?

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by Krull >> Tue, 16 Jan 2001 4:29:33 GMT

Sometimes I have a method that I want to put code in, but I don't want any method to run the method by mistake. It is supposed to be reimplemented in the subclasses, but they will inherit behaviour from this method. Sort of like Partial Abstract-ness. They are reimplemented in concrete subclasses and its behaviour is inherited.

Is this possible, or does this feature need to be added?

You could raise an exception from the top-level default method. Won't be trapped at compile time, but any violations should be picked up in unit-test, which if you are an XPer you will have written first

by JADE Kid - Ray Hidayat >> Tue, 16 Jan 2001 4:32:40 GMT

I have no idea how I can know if the method was run from a subclass or somewhere else.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by Krull >> Tue, 16 Jan 2001 5:09:34 GMT

I have no idea how I can know if the method was run from a subclass or somewhere else.

If you raise an exception from the method that requires reimplementation, when it gets invoked you can just look at the call stack to find the caller. If you want to bypass any default exception handlers that might consume the exception you could code process.debug; in the method, this will unconditionally bring-up a call stack browser if the method is accidentally invoked. JADE currently doesn't enforce that all abstract methods are re-implemented in all concrete subclasses at compile-time; it is only caught and reported at runtime with exception: "1216 Cannot invoke an abstract method" - so raising your own exception (or even a 1216 SystemException if you like) is not a lot different.

by Warwick Hunt >> Tue, 16 Jan 2001 19:54:50 GMT

I think that what Ray wants to do is to put some common code in his superclass implementation of the method, but only ever have it invoked by an inheritMethod call from a subclass reimplementation.

I would achieve this by using a different superclass method for the common code, and making the new method protected.

Warwick

by Krull >> Tue, 16 Jan 2001 20:05:49 GMT

I think that what Ray wants to do is to put some common code in his superclass implementation of the method, but only ever have it invoked by an inheritMethod call from a subclass reimplementation.

After re reading Ray's original post, I suspect you're right. I misunderstood what he was actually asking for.

I would achieve this by using a different superclass method for the common code, and making the new method protected.

Yes, that's how I would do it too.

by Carl Ranson >> Tue, 16 Jan 2001 20:46:17 GMT

I have written some code to do this before....from memory I used one of the jade methods to look up a method by name and then checked the class that it was defined against self.class.

This was one of the projects I worked on for cardinal so I don't have access to the source anymore unfortunately.

but check out the getMethodInHTree method.

btw, read up on how Eiffel does pre and post conditions if you want to see a brilliant way to do what you're trying to achieve.

Cheers
Carlos

by Krull >> Tue, 16 Jan 2001 21:37:41 GMT

btw, read up on how Eiffel does pre and post conditions if you want to see a brilliant way to do what you're trying to achieve.

Carlos

Hi Carlos (Guitar player or Assassin?)

Yes, I am also a fan on 'Design By Contract'

Bertrand Meyer's books on Object Oriented Software Construction (using Eiffel) are recommended reading.

I also have a copy of extracts (chapters 1,2,3 and 6) of a draft book on 'Design by Contract' authored by Jim mecum of Hartford and Richard Mitchell from InferData Corporation. I am not sure if it has been published yet, but it looks quite promising. In the book, Mecum and Mitchell advocate 6 main principles of design by contract .

by Krull >> Tue, 16 Jan 2001 21:52:15 GMT

Oops, finger trouble with the spell checker - Mecum should be McKim

'Design by Contract' authored by Jim mecum of Hartford and Richard Mitchell from InferData Corporation. I am not sure if it has been published yet, but it looks quite promising. In the book, Mecum and Mitchell advocate 6 main principles of design by contract .