Re: [boost] [multimethods] Proposal: Open Multi-Methods

Subject: Re: [boost] [multimethods] Proposal: Open Multi-Methods
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2013-07-31 14:45:57

Hi,

> Are virtual base classes supported?

Yes, at a cost in performance, as usual when virtual bases are involved. 
If the class in the specializer virtually derives from the class 
declared in the same position in the multi-method, dynamic_cast<> will 
be used to adjust "this". Otherwise static_cast will be used. There will 
be a small additional cost for accessing the pointer to the method table 
- or any virtually inherited data FTM.

> Maybe “virtual_” should be renamed to “virtualize” or “virtualized,” to avoid having a trailing underscore in a non-member name.

I'm trying to be as close as possible to the syntax used by Stroustrup's 
proposal - which I like a lot. Virtual is the familiar keyword in C++ to 
denote dynamic binding. Other possibilities would be late<> or 
dynamic<>. A trailing underscore is but one of the decorations some 
people put on data members, AFAIK the practice hasn't reached consensus.

> A good way to document is to write a Doxygen comment as you write your class, function, or macro prototype.

I have used Doxygen in the past and I was happy with it. Not too sure 
it's the best way to document macros and templates, and one base class 
that contains only one pointer for internal use.

> But looking at your “next.cpp” example, you should start with documenting the “selector,” “virtual_,” “MM_CLASS,” “MM_INIT,” “MULTIMETHOD,” “BEGIN_METHOD,” “END_METHOD,” and “initialize” items.

That is pretty much all there is to document indeed. Plus 
MM_FOREIGN_CLASS (for non-intrusive multi-methods), two templates and 
one concept (to use without the macros).

I am very tempted to change BEGIN_METHOD into BEGIN_SPECIALIZER.

>   Anything in your implementation classes that don’t have to be seen by public code can be make private.

I am not convinced of the merit of encapsulating *internal* classes - 
then probably providing getters and setters for all the members. This is 
a small set of classes that collaborate together in secret like friends. 
Don't get me wrong, I am not arguing against encapsulation in general.

> Non-public types can go in a detail namespace.

Exactly! "namespace detail" means "private", don't touch it, you don't 
even know it's there ;) By the way, I'll move come classes (the slot 
allocator and the method resolver) to the cpp file.

Jean-Louis