You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
peterjamesnugent
changed the title
Create result without pulling from software
Structure_Engine: Create result without pulling from software
Apr 11, 2024
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.
Currently,
IResult
objects implementIImmutable
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 ofIResults
from BHoM UIs, for example exposingCreate
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 forIResult
classes in the Structure_Engine.The text was updated successfully, but these errors were encountered: