[vtk-developers] Multiple inheritance

[Will Schroeder]

I think what you proposes has a lot of merit. However I start getting
twitchy when I think what this means in terms of wrapping code, potential
API changes, documentation changes, etc. although maybe it has little
impact. (FYI we actually did try multiple inheritance in the 1993-94 time
frame when we first started implementing in C++ - a very bad experience due
to the awful compilers at that time.) I think for something like this to
move forward a proof of concept is required to better understand what the
impact on VTK would be.

On Tue, Jul 3, 2018 at 11:08 PM Todd Martin via vtk-developers <
vtk-developers at public.kitware.com> wrote:

> 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 <https://gitlab.kitware.com/vtk/vtk/merge_requests/4372>
>
>
>
>
> 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 ...
> <https://gitlab.kitware.com/vtk/vtk/merge_requests/4372>
>
>
>
> 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 <http://www.kitware.com/opensource/opensource.html>
>
> Search the list archives at: http://markmail.org/search/?q= vtk-developers <http://markmail.org/search/?q=vtk-developers>
>
> Follow this link to subscribe/unsubscribe:https://public.kitware.com/ mailman/listinfo/vtk- developers <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
> <http://www.kitware.com/opensource/opensource.html>
>
> Search the list archives at: http://markmail.org/search/?q= vtk-developers
> <http://markmail.org/search/?q=vtk-developers>
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/ mailman/listinfo/vtk- developers
> <https://public.kitware.com/mailman/listinfo/vtk-developers>
>
>
>
>
>
> --
> Unpaid intern in BillsParadise at noware dot com
> _______________________________________________
> 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
>
>

-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180705/4b295049/attachment.html>