search

simphony / simphony-common

The native implementation of the Simphony cuds objects
BSD 2-Clause "Simplified" License
7 stars 5 forks source link

We need a way to check expected shapes of the supported parameters of generated classes #345

Closed tuopuu closed 7 years ago

tuopuu commented 7 years ago

Shape information of the supported and required parameters should be easily accessible from the generated classes. For instance, Box class has a supported parameter condition that has a shape (3). Currently it cannot be read from anywhere else than metadata itself.

tuopuu commented 7 years ago

@stefanoborini , @mehdisadeghi any comments / quick workarounds to this?

I need to be able to read the shapes to recreate CUDSComponents from yaml files, and also to write proper test cases for yaml serialisation methods.

stefanoborini commented 7 years ago

If you are setting a condition, you know what type it must be. If you parse the yaml file, get the info for the condition, and stuff it in, it should raise an exception and if so, the yaml is corrupted.

tuopuu commented 7 years ago

Yes, I'll get an exception if I'm trying to set a condition with data that not exactly in a correct shape and type. That is good enough in the case when the model is read from yaml file back to SimPhoNy, and the yaml file itself has some issues (for instance, an unsupported change made by the user).

However, I need to write a test for the serialisation methods that generates a complicated model, that has all currently defined CUDSComponents (with complicated subcomponent references) in it, and stores/load that to/from a yaml file. In order to do it, I need to dynamically generate CUDSComponents which requires shape information on their required/supported parameters. I have two complicated solutions in mind which I'm not happy with: 1) Read through the metadata and extract the shape information from there. 2) use try/exception blocks to guess the correct shape for each parameter of the components.

I'd like to have a method for each generated class that returns the shape of the parameters. We could modify the supported_parameters method so that instead of a list it would return a dictionary that has the shape information as values.

stefanoborini commented 7 years ago

Can't you generate a complicated one once and for all? Why do you need to create it procedurally?

tuopuu commented 7 years ago

Because new Cuba-keys are constantly added and these need to be tested as well...

stefanoborini commented 7 years ago

When a new key is added, a test for that key is added as well. You are proposing to modify the code specifically to accommodate a need that is exclusively for the test.

tuopuu commented 7 years ago

Yes, this is a use case. Admittedly it sounds kind of irrelevant, but a good thing with it is that having a generated test model for serialisation helps future development so that people don't have to touch serialisation code when adding new keys.

If you think it's too much work or unnecessary with only this use case, we could leave the serialisation tests incomplete so that only simple cases are tested, or that I could exclude certain keys from the tests that are failing right now (because of no shape information available). What do you think?

stefanoborini commented 7 years ago

Without something like traits, I wouldn't know where to put this information without polluting every individual class with a method that provides this information, plus a global method that provides the information about the cuba types.

tuopuu commented 7 years ago

In fact I think shape information should be in the generated class docstrings, which are essentially absent at this point anyway. It could be extracted from there easily, and it would provide information about the class for the user. However, automatically generating docstrings would be another mess... ;)

I'll go with imcomplete tests.