Type Into activity implicit conversion on input parameter to string

Feedback Activities
,
1

Change Type Into activity so that it accepts any data type for the input parameter (System.Object instead of System.String) and implicitly convert to a string.
Now we have to explicitly convert to a string via the “ToString” method whenever we want to type a number, DataTable Item, etc and I think this is redundant and could be avoided.

1 Like
2

Disclaimer - I have very bad experiences with blanket implicit conversions.

I disagree.
With a lot of types it will give either type name or output in wrong format (especially dates and floating point numbers - Europe frequently uses different formatting than Uipath and it already is a common question/error).

Eliminating compiler errors by making them runtime logic errors is imho the wrong way.
Its a similar sentiment that GenericValue brings, unless its literal copy-paste type of operation, most of the time its not what you want. I’m yet to find an example where GenericValue is better than a String, but seen a lot where its worse.

Most safe primitive types support the vb.net string concatenation operator & anyway and from my experience majority of vars are strings in the project.

Aside of saving few keystrokes while potentially hiding errors, what are the benefits?
Imho risks outweigh gains a lot, but maybe I’m just biased.

At the very least if this goes through, please be very explicit about it as it would be a breaking change in one of the corest activities in the whole product.

2 Likes
3

It’s not a breaking change. Now you can have only strings as input for Type Into, in the new version you could have anything, also strings, and the old workflows with strings will work as before, String.ToString will return the same instance.

Also, it could be implemented in a smart way so that it checks the underlying type:

  • If it’s a string, use it directly;
  • if it’s an array, use String.Join(", ", input);
  • if it’s a DataTable, format it like Output Data Table activity;
  • for DateTime and numeric data types, use the CurrentCulture for the conversion;
  • other special cases?

Indeed, for lots of types where there is no direct conversion to a string it will show up the type name, but even in that case we could use .net reflection to get a value from a public property or something.

4

It is a behavioural change, since it will now not report an error (which could be argued is the same of not throwing an exception when one existed before).

It would also change expectations of behaviour in other activities - if one can directly TypeInto an int[], but needs to use explicit conversions to put it into logs (WriteLine/LogMessage) or a file (WriteTextFile/AppendText) the user might not know how to do it, or worse yet, data in the logs might differ from what is actually typed into the application.

That last part could be remedied if an activity for “stringalizing” an object would be added. That way a user could rely on the same implementation doing the conversion (and would help with testing as well).

Please also remember about types with defined implicit conversions to string if this will get implemented.

What if you need a different separator? Similar issues happen with WriteCsv where the delimiter is limited to just 2 options (here it would be 1), which needs workarounds if you need to use anything else.
Also that array could be of any type, leading to recursion needs.

Fair enough, although I think it overloads the purpose of TypeInto a little too much.

This I have very mixed feelings about. In some environments CurrentCulture/CurrentUiCulture is set differently depending on who logs in. This could lead to bugs that are extremely hard to trace and could not show on tests/are not reproducible for devs (no access to prod users directly).

That’s a rabbit hole I’d avoid, but that’s your call. Relying on internal implementation details of other classes for core activities is IMHO a huge risk.
In most cases people that do use those types would generally know how to get the property they need.

Don’t get me wrong - I disagree that it’s needed, but still this is an interesting idea and would align nicely with the goal of making UiPath easier to start with for non-programmers.
But I fear that it’s only the start that would be easier, as it also hides risks that would impact non-programmers the most.

A programmer that would see that the robot is doing an implicit conversion that doesn’t suit his need, will make an explicit one (I’m assuming this is caught in the tests, which should be the case). Later on he will avoid that functionality to make code explicitly do what he wants it to, as relying on internal “magic” conversion is risky to leave in long-term projects (any future change in this implementation could possibly break the project).

But a non-programmer that will have the same situation will treat it as an error in software. He/she will file a bug/ask on forums, get an answer that “for this case you need to use explicit conversion like this [sample]” and next time, with different type, still not know how to do it (but now knowing that a conversion is needed).

In the end I can easily see that this functionality would be avoided on purpose by all implementors, to make sure that data is used correctly (similarly to what is happening with GenericValue in most teams I’ve had the pleasure to talk to).

I’m not seeing a problem that this is trying to solve. Again, I’m probably biased.
Some opinions from others (programmers and not) would be helpful.

What do you think of opening this for a wider audience? Since TypeInto is as core as it gets, a discussion similar to “Simplify Feature Set”/others in public forums could bring value.

2 Likes
5

Hello Guys.

I think is a good idea to streamline certain functionalities but to be honest here I agree with @andrzej.kniola . The field box you are interacting with will expect a string as a general rule and if we let other types of data conversion problems can appear as you don’t know the expected format and encompassing all the possibilities will require a lot of work from our side and I don’t know if it will streamline the processes, but thank you for the suggestion.

Regards,
Cosmin

3 Likes