Buildings and Habitats object Model
Setting to expose constructors of immutable objects #1335
-
|
For some specific tasks it can be useful to expose the constructor of immutable objects that are generally protected. This could be handled by a UI settings object with a parameter One example where this could be useful is creation of datasets, where it might be of benefit to be able to explicitly set some properties that are generally calculated by some engine method. One example of this is the generation of Steel sections in the BHoM where the tabulated values are used over calculated values to ensure it matches up 1:1 exactly with the source. This can ofc be, and currently is, handled by simply adding a create method that is not part of the general framework that allows this exposure, but wonder if a setting like this could handle this case wider and avoid the need of adding this method. Another example is testing, where it could be useful to generate dummy data for testing. Arguments against this is that this might expose to much and that it is better to go with the current strategy of simply adding the required create method when we have the specific need, to avoid having someone accidentally turn on the setting that could lead to generation of invalid/incompatible objects. Happy for up and downvotes on this idea. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
My gut here is to not add the complexity of a UI settings or new feature to handle this. The approach of adding an explicit create method is actually quite flexible and powerful allowing space in the code for good Descriptions and Annotations as to reason for the exposing create method existing, use and requirements etc. Also allows the placement of this specific Create method exposing all properties directly in a different .dll to perhaps the reset of the related engine methods. i.e. if you want methods for dataset creation or testing - these can be separated from the general use engines - and not included in general release installers etc. So current mechanism we have is quite flexible. And formalising anything as additional settings - adds complexity which is nice to avoid where possible. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, happy with not pushing the idea forward. Think you might be right in saying that the potential reward for the added complexity is to small to do this, and the workaround is simple enough so that this can be avoided. Hence, happy for this to be not progressed 👍 |
Beta Was this translation helpful? Give feedback.
-
I fully agree 👍 |
Beta Was this translation helpful? Give feedback.
My gut here is to not add the complexity of a UI settings or new feature to handle this.
The approach of adding an explicit create method is actually quite flexible and powerful allowing space in the code for good Descriptions and Annotations as to reason for the exposing create method existing, use and requirements etc.
Also allows the placement of this specific Create method exposing all properties directly in a different .dll to perhaps the reset of the related engine methods. i.e. if you want methods for dataset creation or testing - these can be separated from the general use engines - and not included in general release installers etc.
This could be something we formalise guidance a…