Added extend feature to information model dsl

[Ebolon]

As discussed in #823 it can be helpful to extend/override attributes of a function block in an information model. The with keyword is already used in another context to give a property additional attributes. Thats why the keyword extend is used. In and extend block all features of a function block can be used. Other like the proposed idea the fields status, etc. are retained because property names between sections are not unique.

Example:

infomodel SenseHat {
    functionblocks {
        gyrometer as Gyrometer extend { 
            status {
                offline as boolean
            }
            operations {
                set_active()
            }
        }
    }
}

The feature could be implemented similar for data types in a function block in the future.

[aedelmann]

So if I Want to just add constraints like min max to an existing property, How would that look like ?
Would I need to define the whole prop again incl description etc ?

[Ebolon]

This is a tough decision. I see to potential options:

Option 1:
It could be nice that it is not required to write all "keywords" again. A with-block could be overwritten with with {} and a comment "". But if a with-block is overwritten all previous defined variables should be deleted. But then we should behave the same way when extends is used.

Option 2:
The property needs to be defined again completely.

For me option 2 would fits best. We assume that most people have used a OOP language. This would give the same experience. Maybe a bit more verbose but easier to understand.

Example for option 2:

namespace com.ipso.smartobjects

functionblock Distance {

   status {
       mandatory sensor_value as float with {readable : true} "Last or Current Measured Value from the Sensor"
       ...    
   }
}

Adding constraints to sensor_value:

using com.ipso.smartobjects.Distance;0.0.1

infomodel MyDistance100MeterDevice {

   functionblocks {
       distance as Distance extend {
            status {
                mandatory sensor_value as float with {readable : true} <MIN:0, MAX:100> "Last or Current Measured Value from the Sensor"
            }
       }
   }
}

[aedelmann]

Hi @Ebolon
Looking at these two options, I think so too, that option 2 is better. But the validation has to make sure that you are not able to override the datatype, as OOP languages would not allow that either. I can see, that your Pull Request is not handling this yet.
Another thing in the context of this: how are these overridden function block properties processed in generators etc ? My idea would be to wrap the current EMF Model into a more convenient domain model that is easier to be processed by other components, like generators or the repository. It could deal with function block inheritance etc and give you a consolidated view on the properties. what do you think ?

Btw: travis ci is failing because of failing unit tests in repository-java client. Can you take a look :-) ?

[Ebolon]

Another thing in the context of this: how are these overridden function block properties processed in generators etc ? My idea would be to wrap the current EMF Model into a more convenient domain model that is easier to be processed by other components, like generators or the repository. It could deal with function block inheritance etc and give you a consolidated view on the properties. what do you think ?

I agree there should be a wrapper class for this.

Btw: travis ci is failing because of failing unit tests in repository-java client. Can you take a look :-) ?

I will have a look. The build works somehow on my machine.

[aedelmann]

Hi @Ebolon
Would you mind adding the necessary DSL validator that validates if the extended properties do not override/clash with the definition from the base function block ?

[Ebolon]

Yep, will have a look next week.

[Ebolon]

Added validation for all properties (status, events, etc.) and operations which can be defined in a FB. The error messages could be improved in the future.

[aedelmann]

Cool. Thanks @Ebolon
I will try it out this week and let you know.

[aedelmann]

Looking at your validation, it seems that it is not checking if there is a clash of a constraint and with statement ? It could be that the base property defines eg a MAX constraint which the overridden property should not be able to override. Same applies for with statement

[Ebolon]

For the constraints I have the idea that it would be feasible to tight boundaries. Here an example:

functionblock BlockA {
    configuration {
        mandatory value as int with {readable: true} <MIN 1, MAX 500>
    }
}

functionblock BlockB extends BlockA {
    configuration {
        mandatory value as int with {readable: true} <MIN 10, MAX 100>
    }
}

How do you think about that?

I am not 100% sure how the validation should behave for the with-block. For example:

functionblock BlockA {
    configuration {
        mandatory value as int with {readable: true}
    }
}

functionblock BlockB extends BlockA {
    configuration {
        mandatory value as int with {writable: true}
    }
}

Should it be ok to change readable, writable, eventable?

When there is a clash between constraints an with-block?

[aedelmann]

@Ebolon
That would work for min and max. That's not a bad idea. I guess as long as the sub definition does not violate the constraint, it is ok. For the others like regex, default etc, it would not allow to override at all, do you agree?
Regarding with block: IMO, Any existance of with definitions would not be allowed to be overridden by base definitions. That includes readable, writable, eventable and measurementUnit.

[Ebolon]

Here is my proposal:

constraint	overridable	comment
MIN	YES	parent value <= value
MAX	YES	parent value >= value
STRLEN	YES	parent value >= value
REGEX	NO
MIMETYPE	NO
SCALING	NO
DEFAULT	NO
NULLABLE	YES	if parent is true it can be overwritten with false

For the with-block I agree. If any keyword is already defined it can not be overwritten.

[Ebolon]

@aedelmann: I have added the intended validation functions for property attributes and constraints. Maybe you can have a look if they work like you would expect. I create the necessary units test afterwards.

[Ebolon]

@aedelmann: Any chance you could have a look at this near-term? Would like to go forward and implement the extend feature for all generators.

[Ebolon]

As discussed I close this pull request now. I will create a new one and remove the inline extend and including only the extends validation.