Merging parameters of different types

Technical
#1

I recently tried to merge two parameters together in 9.11, one is a double and the other a float. I was surprised to see the error message “Value types must match to support merging parameters.”

I thought this functionality (merging different parameter types) had been added already, but maybe I dreamed it. Is there a plan to do this?

2 Likes
#2

@navjodh_dhillon can you check with the R&D team on this?

1 Like
#3

Hi @david-wsd: Merging parameters is still supported, but the parameters names and types have to be the same for the merge to happen.

Data types are predefined for properties and as such, merging parameters of related types such as float and double could lead to data loss for one of the properties, if it were supported.

What was your current expectation on merging in such scenarios?

2 Likes
#4

Hi @navjodh_dhillon, Doh! Not sure why I thought it was supported. :thinking:

Is it a good/plausible feature to be able to merge any numeric-type parameters? You mentioned data loss, and I think I understand the concern.

Let’s say we have two parameters, one double and one float. Of course, the float has lower precision than the double, so there is inherent data loss. But this limitation already exists regardless of whether the parameters are merged. The act of merging doesn’t necessarily cause additional data loss. If the user wants to merge a double and a float, then they clearly intend to set both to the same value, and will do that whether or not merging is supported. Merging just makes it easier for them.

However, I’m sure there would be challenges and nuances with the actual implementation, surrounding how to store the value and convert it to the other types.

Thoughts?

1 Like
#5

@david-wsd: I see your point. However I would say that merging properties with related but not exactly matching types can cause unintended data loss and bugs. Even if initially a user does a merge intentionally like you mentioned, it is easy to forget that later and set a value that is larger than what one of the merged types can hold. C# already restricts assigning values between types and requires explicit cast for situations where there may be information loss. This is easy to overlook when working at the TestStep setting level. And yes, it will also likely be challenging to implement.

But if you do see use cases in your project where this will significantly simplify setting parameter values, I would be happy to revisit it.

1 Like
#6

@navjodh_dhillon Again, this is true regardless of whether the parameters are merged.

The context for my request is this: the user requires that two different parameters are set to the same value, and the user is already successfully setting both parameters individually to the same value. The data-loss dilemma you’re raising (where the two parameters cannot hold the same value) cannot, by definition, occur within that context.

I can only think of two scenarios where the data-loss dilemma could actually occur:

  1. The user is confused about the purpose of a specific property, and is setting the wrong value.
  2. The developer chose the wrong type for a property

In either scenario, somebody is doing something wrong that needs to be corrected, and this is true regardless of whether the two parameters are merged.

So my contention is that merging parameters of different types is harmless and beneficial to working applications, and only presents data-loss issues to applications that are already broken.

1 Like
#7

Okay, I see your point. As I thought more about it, I realized that what you said applies very well, but to one scenario out of two and I’ve been thinking of the other scenario. Here are the two scenarios (assuming the developer who set different data types on the properties did it on purpose):

  1. The value being set fits within the size of both (or more) of the properties. Yes, as you said, the user can set those properties individually and it continues to be a valid use case for merged properties.
  2. Let’s take into consideration this other scenario where the larger property was supposed to hold a numeric value larger than the smaller property’s size. Of course, in this case a user wouldn’t merge properties in the first place as those were supposed to hold different values, and this is obvious when the user looks at those properties in Step settings. But scenario 2 can occur after scenario 1 which means the properties were merged in the past to address scenario 1 and that’s where the possibility of overlooking the difference in properties’ data types applies. Again, it usually wouldn’t happen, but merging obscures underlying properties to look like it’s just one value compared to working with individual properties directly in the Step. I hope this explains my point.

Like I mentioned previously, if you do have a case where having this capability will significantly simplify setting parameter values, I think despite my concerns it is worthwhile to run it by our development team. Perhaps, it is possible to implement such a capability and add warning or error messages to make the user aware of the differences in data types and prevent pitfalls.

2 Likes
#8

@navjodh_dhillon I completely agree with your assessment.

It would certainly be a handy feature for us. On the other hand, I may have needlessly chosen different types for the two properties, and can enable the merge by making the types match. Let me look further into that. It’s not an urgent request. Thanks for hashing it out with me!

4 Likes
#9

@david-wsd: Just wanted to update you that I had made a note of your feature request earlier and I’m discussing with our R&D team on if and how it can be implemented in a safe way.

3 Likes
#10

Hi @david-wsd : R&D team agreed to do an implementation for your request. You can track it here: Support for merging related numeric types in test plan parameters (#497) · Issues · OpenTAP / OpenTAP · GitLab

3 Likes
#11

Thanks @navjodh_dhillon , that’s great!

1 Like