[vehicle_spec] recursive definition in Zone not problem? about automotive HOT 4 CLOSED

Whether or not this becomes recursive is an implementation detail. I got
it to work avoiding infinite recursion by, iirc, overriding the getter in
the "driver" attribute and making it not enumerable (which iirc is the
default).

On Wed, Jul 29, 2015, 1:40 PM Shinjiro Urata [email protected]
wrote:

interface Zone {
attribute ZonePosition[] value;
readonly attribute Zone driver;
boolean equals (Zone zone);
boolean contains (Zone zone);
};

interface Zone uses Zone itself inside the definition.
To think straight forward, constructor of Zone need to construct another
Zone inside and it is recursive. I suppose this is problematic.
To avoid this recursion, one idea is to use getDriverPosition() method.

But another thing I think is, if we need driver position inside Zone
definition or not.
It looks we can get driver position from interface
steeringwheelConfigutation.
So I guess it would be no problem to remove driver position from Zone
definition.

interface Zone {
attribute ZonePosition[] value;
boolean equals (Zone zone);
boolean contains (Zone zone);
};

—
Reply to this email directly or view it on GitHub
#55.

from automotive.

@tripzero thanks for the comment.
I suppose you mean this.

window.Zone = function(zone) {
    this.value = zone ? zone : [];

    Object.defineProperty(this, 'driver',
                          { enumerable: false, get: function() {
                              return new Zone(['Front', 'Left']);
                          } });
};

https://raw.githubusercontent.com/otcshare/automotive-message-broker/master/xwalk/vehicle_api.js

OK. I get it.
We are thinking about C++ layer implementation and maybe there is some workaround.

Then how about this point?

But another thing I think is, if we need driver position inside Zone definition or not.
It looks we can get driver position from interface steeringwheelConfigutation.
So I guess it would be no problem to remove driver position from Zone definition.

From a point of view, driver position is suitable to be handled by Configuration and Ideintification interface and enough by having steeringWheelConfigutation interface.
Is there a special reason to have it inside Zone interface?

from automotive.

There is a valid point about the redundancy. There should only be one way
to avoid confusion.

On Thu, Jul 30, 2015, 4:32 AM Shinjiro Urata [email protected]
wrote:

@tripzero https://github.com/tripzero thanks for the comment.
I suppose you mean this.

window.Zone = function(zone) {
this.value = zone ? zone : [];

Object.defineProperty(this, 'driver',
                      { enumerable: false, get: function() {
                          return new Zone(['Front', 'Left']);
                      } });

};

https://raw.githubusercontent.com/otcshare/automotive-message-broker/master/xwalk/vehicle_api.js

OK. I get it.
We are thinking about C++ layer implementation and maybe there is some
workaround.

Then how about this point?

But another thing I think is, if we need driver position inside Zone
definition or not.
It looks we can get driver position from interface
steeringwheelConfigutation.
So I guess it would be no problem to remove driver position from Zone
definition.

From a point of view, driver position is suitable to be handled by
Configuration and Ideintification interface and enough by having
steeringWheelConfigutation interface.
Is there a special reason to have it inside Zone interface?

—
Reply to this email directly or view it on GitHub
#55 (comment).

from automotive.

I understand.
Personally, still I think, driver position can be located in Configuration and Identification interface.

from automotive.