PropertyValue method could fallback to call RunExtensionMethod

[IsakNaslundBh]

Current PropertyValue method that is at the core of our GetProperty method currently checks for defined properties as well as for values in custom data. I know this will also be expanded to a search of the fragments.

Wonder if a final last fallback could be to call RunExtentionMethod with the provided property name as assumed method name. That way you could for example provide a Bar and ask for "Length" and it would fall back to fetching the length via the Query method in the structures engine.

The benefit I would see to this would be pretty much the same as the downside I would see to this; it blurs the boundary between Defining properties and Derived properties. This could make the use a bit more simple, that engineers using the tools does not have to know if they need to use get property or a query method to fetch some particular piece of information, but it will also mean a separating between the data you can directly get from GetProperty and Explode.

I think the benefit could outweigh the downsides, but glad to get other peoples opinions!
@adecler @FraserGreenroyd @al-fisher @alelom @pawelbaran

[pawelbaran]

Sounds like a nice improvement in one direction (get, even if a bit confusing in defining vs derived), but I can imagine the users being confused when attempting to set derived properties. I have a feeling this could be a step too far in trying to make user's life easier.

However, maybe an informative warning could pop up in case there was an existing Query method under the given name?

[al-fisher]

I think this sounds very good.

The asymmetry of some properties not working on Set - when they do on Get
And also the properties returned on Explode being only a subset of those accepted in GetProperty - can actually all help to reinforce the concepts and difference between Defining (Get; Set) and Derived (Get only)

Like it.

[adecler]

I am on the fence on this one. I am always worried about features that can cause bug being reported due to (understandable) lack of knowledge of internal workings. From a C# perspective, it is always very easy to find out of a property is settable or not. From a UI perspective, not so much. So I can already see the screenshot of a red SetProperty component next to a working GetProperty component.

Don't get me wrong, I think this is a nice feature but I think we would need to solve the disparity between C# and UIs before we can consider this as a safe feature to add.

[IsakNaslundBh]

So I can already see the screenshot of a red SetProperty component next to a working GetProperty component.

Very good point, and a clearer example (that I actually did not think of) of the kind of issues that would be my worry against doing this.

One idea, would be to change the name of the GetProeprty component to something like GetData or similar, but not sure how much it solves it anyway (dont think this is good enough/something we should do, but keeping as a note for reference).

We could also mimic the behaviour on the SetProperty component, to have it fallback to also call RunExtensionMethod, maybe with an added "Set" in front. Then some cases like setting geometry would work for at least some objects.

Could also, potentially, have the SetProperty component, if it fails to find a proeprty, check if there is a "getable" query method with the name, and then give a more informative error message, such as "The property you are trying to set is a derived property extracted from a query method and can not be set. Try exploding the object to find its set-able properties". Would at lest potentially solve the situation you mention above Arnaud, but probably not everything..

[al-fisher]

I am not too worried about the same property not always working for both Set as well as Get. In fact I think this is a good thing that we need to communicate well to the user.

In the case of say Length being put into both Get and Set - an Error message simply stating "Length is not a directly settable Property" will be clear.
Which reading again - is basically your last point above @IsakNaslundBh - about checking if there is a Gettable matching name

[alelom]

Agree with @al-fisher on this one - a clear error message to communicate a non-settable property can do the job. I also find it rare that we will have cases where a user will try to set a derived property (i.e. trying to set the perimeter of a Rectangle). If such a case becomes common, then the definition of the class/derived property itself should be put in discussion.

[alelom]

The problem comes more on how to inform the user of what derived properties are gettable. We can't ask the user to guess what is available. Some ideas:

• list all derived property names in the description text when hovering the parameter/output
• when exploding an object, the explode component exposes an extra derivedProperties output that lists all derived property names as List ("...you can also get these by using GetProperty").

[IsakNaslundBh]

A bit of a bumb to this idea, with another use case that would be in favour of adding this mechanism, namely the filtering and grouping and ordering methods we have in the Data_Engine.

Adding this RunExtentionMethod mechanism to the PropertyValue method would allow for those methods to be used with this as well. Could for example be ordering a list of bars by their length or similar, which I think could be a really powerful addition.

[pawelbaran]

Which scenario do you have in mind when thinking of this being powerful? Sorting by key/value seems to be pretty easy in all environments we work with, so I do not buy it. However, can imagine this being different e.g. while clustering etc., is that where you come from?

[IsakNaslundBh]

Agree, sorting might not be the most powerful, but grouping, and as an extension clustering for sure could be. Grouping in native GH is relatively tedious imo and requires quite a lot of expertise in GH, while a GroupBy or ClusterBy component would be significantly simpler to use :)

[al-fisher]

@alelom effectively implemented this feature as needed as part of the Specifications work we did.
So I would be supportive of promoting down to "core".

https://github.com/CIHDigitalConfigurator/CIH_Toolkit/blob/master/CIH_Engine/Query/ValueFromSource.cs

[alelom]

Thanks @al-fisher for remembering this - and yes I agree on this idea @IsakNaslundBh.

The only problem I can see is how to inform the user of what derived properties are available, see my comment here.