method foobar(c:TBaseObject) {. abstract .} #need not/cannot be implemented because abstract
method foobar(c:TInheritedObject): ... #has to be there, or compiler error because base object has this function marked as abstract
If this feature does not exist, is it a reasonable feature request? It simplifies things a lot in large object hirearchies...
You could enforce abstraction through templates for the procs. See these two files:
# the_abstract.nim
type
Tabstract* = object of TObject
age*: int
template gimme_your_age(thingy: Tabstract): int =
## Returns the age of the thingy.
##
## ATTENTION: All classes need to implement this template as a proc!
{.error: "abstract proc, implement it please!"}
when isMainModule:
var something: Tabstract
something.age = 3
echo($something.gimme_your_age())
# no_tract.nim
import the_abstract
type
Tperson* = object of Tabstract
name*: string
proc gimme_your_age(thingy: Tperson): int =
## Returns the age of the Tperson object.
result = thingy.age
when isMainModule:
var something: Tperson
something.age = 3
echo($something.gimme_your_age())
This will not work for methods, because a method must be implemented for the base object.
Because its with methods abstraction is really usefull, your suggestion is a no-go
Hmm... reading through the methods documentation the only difference seems to be procs are compile time and methods are at runtime, so instead of a template you can use a method which calls quit() in the abstract implementation.
Oh, look at http://nimrod-code.org/tut2.html#dynamic-dispatch, the example describing methods defines an abstract class precisely with this kind of dummy method. Does that example not work for you?
The example works as expected, however, what i'm requesting is a way to make it impossible to compile the code if the abstract methods are not overridden.
I want this because it's very easy to forget to implement abstract funtions in large hirearchies of inherited objects.
If the base method just calls quit(...), the program will compile, but just abruptly terminate in case of method called.
Well, in my case right now I have a general base object TCurve2d, which represents a general/abstract curve in 2d space. Then there are lots of curve types (line arc ellipse bspline bezier etc.) which implements a bunch of methods that all 2d curves can support, such as length, closest point, intersection etc.
So that is not really a mess but a common pattern in computational geometry. I understand this feature is not of highest priority, but i put up a feature request, and maybe i'm lucky in the future.