search

BHoM / BHoM_Engine

Internal manipulation of the BHoM
GNU Lesser General Public License v3.0
26 stars 12 forks source link

Structure_Engine: Create result without pulling from software #3329

Open SBileng opened 3 months ago

SBileng commented 3 months ago

Currently, IResult objects implement IImmutable and therefore have one or more specific constructor in the class definition itself. However, these constructor don't seem to appear in the main BHoM UIs, therefore there isn't any possibility for the users to instantiate them if required. We think there could be a good use case to allow the creation of IResults from BHoM UIs, for example exposing Create methods for them.

This would be useful in particular workflows that we've already encountered. In particular, we'd like to instantiate Results to work with results from calculations that have been done in a software that currently doesn't support the pull of Results, like happens for the RFEM_Adapter. In this case, the RFEM does support exporting results from its UI, i.e. they can be exported in a CSV/spreadsheet. In this case, we would benefit from mapping the exported results to BHoM results, so we can apply to them the many BHoM methods that help process IResult objects.
We are currently working around this limitation by using a C# script component where the IResult constructor is called to instantiate results.

We've discussed this with @alelom who agrees it could be a good argument for developing Create methods for IResult classes in the Structure_Engine.

IsakNaslundBh commented 3 months ago

Hi @SBileng .

I do not really see any issues against adding create methods for results. The reason the results have been made immutable mostly has to do with ensuring compatibility and to give some level of protection for the more common use case, but can for sure see use cases where it would be useful to generate various IResults "manually" in something like Grasshopper.

If you want to have a go at adding a couple of those create methods yourself I am happy to support in review (think @peterjamesnugent will be happy to support as well, but will let him speak for himself).

Can add that you do not need to add create methods for every single result in a single PR, but could start with something that you need, say BarResults or whatever it might be, and leave the slightly more complex results such as MeshResult to a subsequent PR.