ComputationNode inheritance on DPIM about dice-models HOT 3 OPEN

this is indeed incorrect, since both filter and source can have their own computation node at deployment-time... If you elaborate a bit more on why you removed the inheritance perhaps we can strike a balance :)

from dice-models.

I did not remove the inheritance relationship.

I simply found out that when I checked the files in GDrive, FilterNode and SourceNode are subclasses of ComputationNode in DPIM v3. However, these inheritance relationships were removed in v4 (which is the one used to create this project).

I just wanted to know if the deletion of the inheritance was done on purpose or was a mistake (and should be restored).

from dice-models.

ok good!! in summary, we have to keep that relation, I think the requirements deliverable has other details on that if at some point we need to document that and similar relationships ;)

On 19 Nov 2015, at 12:38, Abel Gómez [email protected] wrote:

I did not remove the inheritance relationship.

I simply found out that when I checked the files in GDrive, FilterNode and SourceNode are subclasses of ComputationNode in DPIM v3. However, these inheritance relationships were removed in v4 (which is the one used to create this project).

I just wanted to know if the deletion of the inheritance was done on purpose or was a mistake (and should be restored).

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

from dice-models.