[vtk-developers] Multiple inheritance

Tue Jul 3 23:06:07 EDT 2018

Hi Bill

I'm familiar with generics, but it doesn't address the issue here. Defining a base class with knowledge of the behaviour or attributes of its descendant classes is a violation of the Polymorphism principle.

Todd Martin, PhD.
Freelance Engineer/Software Architect.

    On Tuesday, July 3, 2018, 3:06:56 PM GMT+12, Bill Lorensen <bill.lorensen at gmail.com> wrote:  

 You may want to look at generic programming to solve your problem.http://www.cs.rpi.edu/~musser/gp/GPtutorial/GPtutorial-print.pdf

On Mon, Jul 2, 2018 at 4:31 PM, Todd via vtk-developers <vtk-developers at public.kitware.com> wrote:

On 3 Jul 2018 9:07 a.m., Paul Douglas Hahn <pdhahn at compintensehpc.com> wrote:

 revise "base classes" -> "interface classes"

 On 07/02/2018 04:04 PM, Paul Douglas Hahn wrote:

 Just one caveat (you probably already know and agree with this). In my experience using C++ multiple inheritance, I think you should try to avoid situations where you have common base classes in the inheritance pathways. Virtual base classes are the usual recommendation to resolve certain problems that arise in such  cases, but IMHO having experience with that, I generally recommend against it.

 So I recommend your base classes should be of the "mix-in" interface category, not relaying on any common base class. The approach works fine for me in almost every situation.

Thanks Paul. That sounds exactly like what I have done with the vtkCellWithEdges and vtkCellWithFaces classes introduced in the aforementioned merge request.

 - Paul

 On 07/02/2018 12:44 AM, Todd Martin via vtk-developers wrote:

    Single inheritance languages like Java and C# utilize interfaces extensively. Python 2.7+ handles the same concept with abstract base classes, ABCs.

   Is there any interest in supporting interfaces in VTK via multiple inheritance from abstract classes (which do not inherit from vtkObject) while retaining the single  inheritance model?

 In my view there are good reasons to do so. For example vtkCell has methods like GetNumberOfEdges(), GetEdge(), GetNumberOfFaces(), GetFace() etc. which really only apply to multi-dimensional cells (both linear and non-linear); i.e. not points and lines. These methods are forced on the base class design by a single inheritance  structure and the linear/non-linear cell sub-types. In my view it would be better if they were distributed across the sub-classes via the concept of interfaces. So I'm suggesting a limited use of multiple inheritance here, not a free-for-all approach. What do others think about this?

  For an example please see this merge request Add missing size hints and bug fix point arrays for non-linear cells (!4372) · Merge  Requests · VTK / VTK      

|  
|  
|  
| 
  | 
  |

  |

  |
|  
| 
  |  
Add missing size hints and bug fix point arrays  for non-linear cells (!4...

I've added size hints for concrete public  methods GetParametricCoords(), GetEdgePoints() and  GetFacePoints() in ...
  |

  |

  |

    Todd Martin, PhD.
  Freelance Engineer/Software Architect. 

 ______________________________ _________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q= vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/ mailman/listinfo/vtk- developers

 -- 
Paul D. Hahn
CompIntense HPC, LLC

 -- 
Paul D. Hahn
CompIntense HPC, LLC

______________________________ _________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q= vtk-developers

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/ mailman/listinfo/vtk- developers

-- 
Unpaid intern in BillsParadise at noware dot com  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180704/f237d4a2/attachment-0001.html>