search

anuragraghavan / franca

Automatically exported from code.google.com/p/franca
0 stars 0 forks source link

Franca, DBusConnector and inheritance #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Franca supports inheritance on structures, and these structures can be used as 
the types for the arguments of methods.
So I can have for example:

    method getLocation {
        in {
        }
        out {
            Location location
        }
    }

    struct Location {
    }

    struct PointLocation extends Location {
        UInt32 segment
        UInt32 positiveOffset
    }

    struct LinearLocation extends Location {
        UInt32[] segments
        UInt32 positiveOffset
        UInt32 negativeOffset
    }

In a language that supports inheritance, I would now expect that I can call 
getLocation() and get e.g. a LinearLocation as a result.

However in this case the DBusConnector generates:

    <method name="getLocation">
      <arg direction="out" name="location" type="()">
      </arg>
    </method>

The type for location is just Location, which is in this case an empty struct.

A workaround for this can be:
- Adding a union definition:

    union LocationUnion {
        PointLocation pointLocation
        LinearLocation linearLocation
    }

- And changing the method declaration to:

    method getLocation {
        in {
        }
        out {
            LocationUnion location
        }
    }

In this case the DBusConnector generates:
    <method name="getLocation">
      <arg direction="out" name="location" type="v">
      </arg>
    </method>

So now the type is a variant, which can hold a Location, PointLocation or 
LinearLocation (and of course anything else).

How should this be handled?
Some options:
- The DBusConnector automatically recognizes inheritance, and makes the type 
variant.
- The mapping from inheritance to union is done in a configuration file, used 
by the DBusConnector.
- Just use, and document, the 'workaround', which isn't nice for languages that 
support inheritance.

Original issue reported on code.google.com by peter.go...@gmail.com on 2 Apr 2013 at 1:50

GoogleCodeExporter commented 9 years ago 
Set to RFC in order to initiate a discussion.

Original comment by klaus.birken@gmail.com on 17 Apr 2013 at 4:22

GoogleCodeExporter commented 9 years ago 
I believe that a developer using Franca should need to cope with the 
limitations of a generator as little as possible, be it the DBusConnector or 
any other generator. Franca provides the possibility to define polymorphic data 
types, and as an user that uses the code generated from a Franca interface I 
would expect polymorphic data types to work precisely as such.

It is true, the generated D-Bus introspection exposes the fact that the Franca 
parameter was converted to a variant for reasons the user now needs to 
understand, but I think this is easier to understand and cope with than the 
other two suggestions.

Therefore, I support solution 1, i.e. the automatic recognition of inheritance 
and handling it accordingly, with the mechanisms being as intuitive and close 
to "real" polymorphic types as possible.

Original comment by rauw...@itestra.de on 19 Apr 2013 at 3:32

GoogleCodeExporter commented 9 years ago 
It is hard to decide from a Franca IDL file if a certain method argument of 
type struct should be handled in a polymorphic way or not. One can never know 
if some other IDL file references to the struct in question and extends from 
it. Thus, it seems inevitable to provide this information already in the IDL.

A similar issue (related to code generators) has been raised in issue #39. A 
solution has been proposed there, see the comments. I set the deadline of this 
RFC issue to the same as for issue #39 (CW23). If there is no veto and no 
better solution until then, the proposal of #39 will be implemented. This 
solution will allow to make the DBus-transformation aware of polymorphic cases 
and enables it to generate different introspection XML depending on if the 
struct is marked as polymorphic or not.

Original comment by klaus.birken@gmail.com on 15 May 2013 at 3:14

GoogleCodeExporter commented 9 years ago 
Final RFC result (deadline 2013/cw23): There has been no veto against the 
proposed solution. The polymorphic-keyword will be implemented as described in 
issue 39.

The Franca=>DBus-transformation will be adapted in order to respect the 
polymorphic keyword properly.

Original comment by klaus.birken@gmail.com on 12 Jun 2013 at 9:45

GoogleCodeExporter commented 9 years ago 
Implementation of "polymorphic"-keyword is available (see issue 39). 

The Franca=>DBus-transformation has been adapted, too. If a struct (or its 
derived structs) is marked as polymorphic, the representation in DBus 
Introspection format will be "(iv)". I.e., it is represented as an integer tag 
(typically defined by some enumeration) and the actual data. The data has to be 
defined as variant type, because by looking at just one interface it cannot be 
decided which derived struct will be actual be communicated.

The changes will also be part of v0.8.8.

Original comment by klaus.birken@gmail.com on 12 Jun 2013 at 11:31

GoogleCodeExporter commented 9 years ago

Original comment by klaus.birken@gmail.com on 11 Jul 2013 at 11:26