On Sunday, 24 July 2016 at 15:41:55 UTC, Lodovico Giaretta wrote:
On Sunday, 24 July 2016 at 15:28:53 UTC, Jonathan Marler wrote:
Whoa wait a second...I didn't know you could do this. I
thought everything had to inherit from the object class. Can
you share the syntax to define a class that doesn't derive
from object?
Currently, you cannot. Everything inherits from Object. I
personally think this is not the best idea. But it's not that
horrible either, so probably not worth a big change.
But you can just ignore it. You can put on your opCmp all the
attributes you want and forget about it inheriting from Object.
You can decide to never write a method that takes Object.
Always take the root of your sub-hierarchy, so that you know
what attributes you have.
If it derives from Object or not, nobody cares as long as your
sub-root overrides all opXXX with new (even abstract)
declarations that have @nogc.
This is one of those problems that are going to have pros and
cons either way you go. It's the balance between generality which
yields facilities for sharing code, and specificity which
inhibits shared code. Templates provide an interesting middle
ground for this by allowing you to instantiate an infinite number
of implementations that will fit wherever you want on this
spectrum. But templates don't work with virtual methods :(
Just spitballing here, but why weren't the methods on the Object
class defined in interfaces instead?
interface Hashable;
interface Comparable;
interface Stringable;
I'm sure there's some big drawback to designing it this way, but
the reason is escaping me at the moment. Can someone enlighten
me?
(Note: if a feature like this
(http://forum.dlang.org/post/[email protected]) was implemented, the interfaces could still provide default implementations)
