etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Veith (JIRA)" <>
Subject [jira] [Updated] (ETCH-222) Refactoring of EtchObject TypeHandling
Date Thu, 08 Aug 2013 13:58:50 GMT


Martin Veith updated ETCH-222:

    Fix Version/s: 1.4
> Refactoring of EtchObject TypeHandling
> --------------------------------------
>                 Key: ETCH-222
>                 URL:
>             Project: Etch
>          Issue Type: Task
>          Components: binding-cpp
>            Reporter: Martin Veith
>            Assignee: Martin Veith
>            Priority: Minor
>             Fix For: 1.4
> At the moment a derived class of EtchObject can set the EtchObjectType only through the
constructor. This causes that every class has to provide a constructor to set the EtchObjectType
information. If someone would like to derive from a certain class, this class must have a
special constructor to be able to set the EtchObjectType correctly.
> Therefore we need another method named setObjectType(EtchObjectType of current object,
EtchObjectType of the parent, EtchObjectType of component (if it is an array), int dimension
(if it is an array)) which is implemented by EtchObject. Each individual class has to call
the setObjectType in its constructor to set the correct type information. 
> The type hierarchy can then be stored in a List in EtchObject. This makes it possible
to extend EtchObject  with another method "instanceOf" to check the dependency graph. 
> One example would be the dependency hierarchy EtchObject -> EtchTypeValidator ->

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message