[Rock-dev] Inheritance in base/types - the natural way to go?

[Steffen Planthaber]

Hi,

I cannot help you with the eigen types question, sorry.

But want to re-raise an old (unfinished) discussion on extending types.

Back then, we needed a commands::Motion2D with a timestamp, when the 
command was issued to be executed on the robot.

So basically a commands::Motion2D extended with a base::Time.

To do this I created a Template class "Timestamped" 
(base/types/base/templates/timestaped.hpp) so the timestamp could easily 
be added to any other type by creating a class by inheritance like:

class Motion2D : public TimeStamped< commands::Motion2D >{
     public:
     Motion2D ():TimeStamped< commands::Motion2D >(){}
};

(implemented in base/types/base/samples/CommandSamples.hpp)


The former discussion started, when I directly pushed the changes to 
base/types without discussing it on this List. But the discussion never 
finished and the base/types package was not changed afterwards.


But I think having uncertaincies is a similar extension of types as 
timestamps are. So we can now talk about the best way to implement such 
extensions of types.


For my point of view, using such a template and inheritance has some 
things on the plus side:

- Changes on the base class are automatically "applied" to the extended 
class
- A template class makes it easy to create extended types in any 
component (outside base/orogen/types), when needed



If we can agree on this, we should still change the structure of 
base/types to deal with extensions.

I'd propose this structure:

- backward
- commands
- samples
- extended
  - templates
   - Timestamped.hpp
   - Uncertain.hpp
  - samples
   - UncertainTransform.hpp
  - commands
   - TimestampedMotion2d.hpp


The naming sceme reflects the way the template is read:
UncertainTransform : public Uncertain< Transform >



additionally, there is the possibility to add an constructor from the 
base class:
TimeStampedMotion2D (const commands::Motion2D &from):TimeStamped< 
commands::Motion2D >(){};

This allows to write a standard Motion2D to a TimestampedMotion2d Output 
port. Input ports did not allow polimorphism, but it was discussed for 
RTT some time ago, but I can't recall the outcome.

For Output ports the result of the discussion was that we should not to 
that, as the component dev should think about what is written into the 
extra information before writing it to the output port.
For input ports this could be beneficial, as one could connect and 
UncertainTransform output port to a (old) Transform input port and 
easily re-use older components only supporting the base type.
On the other hand, this possibility could make the dev think the old 
component can handle uncertainties because the port connected, but it 
doesn't.

Also we could think of a more generic way to add meta information to 
types by combining two types into a new one, like a 
std::pair<Transform,Uncertainty> ?
As far as I remember, typelib cannot handle multiple inheritance for a 
single type, correct? I currently have no idea how to do this. Using a 
std::pair is not the solution as accessing the content requires using 
pait.first and pair.second. So the handling differs from the original types.

Now a short summary of the questions involved:
(perhaps you can copy/paste this part to your answer to collect the 
opinions):

- Use Inheritance? +1
- Use Templates for Extensions? +1
- Restructure folders in base/types to reflect extensions? +1
- Autoconvert extended and base types? -1
- Generic Metadata in types? +1


Kind regards,

Steffen


Am 09.04.2015 um 18:54 schrieb Javier Hidalgo Carrió:
> Hi rock-dev,
>
> Since typelib supports inheritance (e.g.: base/samples/Joints <:
> base/NamedVector<JointState>), inheritance seems to me the natural way
> to go when extending classes (e.g. base/Transform3d <:
> base/TransformWithUncertainty). Is there any particular problem with
> Eigen types?
>
> This would help different data-type port connections by subtype
> polymorphism. Would it be compliance with typelib (or with any part in
> the dark-side of the galactic core)?
>
> Regards,
>
> Javier.
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>


-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber at dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  -----------------------------------------------------------------------
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:    DE 148646973
  Steuernummer:  19/673/0060/3
  -----------------------------------------------------------------------