#4564 make Grob an abstract class

[Anonymous]

Originally created by: *anonymous

Originally created by: nine.fie... (code.google.com)@gmail.com
Originally owned by: nine.fie... (code.google.com)@gmail.com

Make Grob an abstract class in preparation for deriving grob interface classes (e.g. Accidental_interface) from Grob without risking unintentional instantiation anywhere.

https://codereview.appspot.com/260810043/

[Google Importer]

Originally posted by: dak@gnu.org

Deriving grob interface classes from Grob would appear to lead to grobs getting derived in turn from multiple interface classes.  Which would imply virtual inheritance in order to avoid multiple Grob base classes.  And so on: basically this looks like you want to end up using the whole multiple inheritance machinery of C++.  Which would throw a complete spanner into extending the grob/interface hierarchies from Scheme and probably turn out tricky with respect to smobification.

So maybe put your ultimate goals out to discussion before investing too much work in it?

[Google Importer]

Originally posted by: nine.fie... (code.google.com)@gmail.com

I was merely hoping to allow something like this:

class Accidental_interface : public Grob { ... }

Accidental_interface *acc = get_interface<Accidental_interface> (grob);
if (acc) {
    acc->do_something ();
}

get_interface<T>(grob) would check that the grob implements the T interface and do a static downcast.

That way, methods in the interface can call grob methods via the implicit this pointer.  That fits with your hopes to convert scheme callbacks into member functions, doesn't it?

I thought this patch had merit on its own, since nobody is instantiating a base Grob anyway, but if you disagree, I can retract it and combine it with future changes.

[Google Importer]

Originally posted by: pkx1... (code.google.com)@gmail.com

Passes make, make check and a full make doc.

Labels: -Patch-new Patch-review

[Google Importer]

Originally posted by: dak@gnu.org

Re #2: where is the point in that?  Basically, you are declaring something as Accidental_interface * which isn't.  You cannot call any member function of Accidental_interface through it since the underlying Grob object is not derived from Accidental_interface.

My "hopes to convert scheme callbacks into member functions" don't extent to calling "member functions" on objects not actually derived from the class of which the member function is being called.

[Google Importer]

Originally posted by: nine.fie... (code.google.com)@gmail.com

Perhaps we can continue this discussion on the dev list.  Do you object to this patch in itself?

[Google Importer]

Originally posted by: dak@gnu.org

In as far as the patch tries to create a type relation between derived classes that is not intended to even reflect any sensible object relation, I do object to this patch in itself.

I cannot claim an absolute ban over such pointer abuse since the classes defined in lily/include/small-smobs.hh similarly abuse a this-pointer and member functions for carrying information unrelated to actually existing objects.  However, in that case this is a trade-off allowing for easy conversion between SCM objects with and without extra allocated memory and thus is connected to actual matters of efficiency.

I don't see any comparable tradeoff here that would serve to justify the abuse of the type lattice.

[Google Importer]

Originally posted by: dak@gnu.org

Expounding on #6: an actual class lattice reflecting the actual relations would be to have interfaces derive from a _virtual_ Grob base class and have a derived Grob type, in turn, derive from all its interfaces.

In that case, the grob's member function can use all member functions of its interfaces, and those may in turn use the member functions of the basic Grob type, with dynamic_cast working whenever it is sensible.

However, we don't use virtual inheritance anywhere else, and one would have to think carefully about how to extend this to Scheme-defined interfaces/grobs.