Change Cluster Data Type

[Mitch_Peplow]

I might be asking a really silly school boy question here and to some degree I hope I am but could somebody tell me if its possible to change the data type of a cluster element? Let me explain.

Here is a screen shot of my code:

 

I read back my test data as an array of strings which I convert to a cluster, bundle then send off on its merry way to do other stuff, however the first element in the cluster is actually a path. As you can see I currently unbundle all elements, change the first to a path then re-bundle with the correct data types. Whilst somewhat messy, this used to be acceptable as I only had two other strings in the cluster, however due to expansion I now look at it and think that there must be an easier, more elegant way to do this if I just want to change one element.

If this is the only way (or at least if no other simpler solution exists) then I could potentially keep the path a a string and do the conversion at the points that require it, however that would now require a bit of re-coding which I would like to avoid if possible.

Hopefully I'm just not thinking hard enough on this one.

Cheers for looking

Mitch 

[crossrulz]

First of all, just use Index Array instead of the Array To Cluster and Unbundle.  One step instead of two and you avoid a huge common mistake of not changing the cluster size in the Array To Cluster function.

Another option I'm juggling in my head is to use a FOR loop to iterate through the array and use a case structure to set the right element using Bundle By Name.  I'm not really liking this idea, but it is an option.

[Mitch_Peplow]

Hi crossrulz,

Firstly cheers for the reply, much appreciated.

Forgive my stupidity but how would indexing the array solve this as I would still have to bundle each element? A standard unbundle and bundle also can't be used as it requires the original cluster data type which is why I was forced to do the method shown which forces the bundle into the new data type cluster constant. Hope that makes sense.

I do agree thought that indexing the array stops you forgetting about setting the correct cluster size which is a pain in the backside as it doesn't complain that you the have more input elements than the wired output cluster but will still let you run! I've stung myself enough times not to make that mistake anymore

The FOR loop idea would and does work as I already tried that before posting this question, however its more cumbersome than I would like, especially for its intended purpose.

Thoughts, comments?

[Darin.K · Accepted solution]

I have no idea what the rest of the code looks like and how much you can change so a few options:

1.  Keep them all as strings, do the path conversion when you actually need the path.  I'll show you the trick I use to convert arrays to nicely labelled clusters below.

2.  Make the cluster an object, keep the data as a string array and the accessors deal with indexing and path conversion.

3.  Make the cluster hierarchial, separate the path and have a second cluster which is all strings. 

4.  If you want you can jigger the string array and use some flatten and unflatten action.

The top of the snippet is one way to jigger the string array to get a path for the first element in a flat cluster (should wire seamlessly to the rest of your code).  The lower code shows how I would convert a string array to a cluster so the labels are useful, same idea works for clusters which are given useless labels such as those from Array to Cluster.  (Fixed sized clusters with brown wires are easier to handle, simply Type Cast to the cluster with the same types and appropriate labels).

Judging from your original post, you know when and how to Type Def the various clusters I show.

[Mitch_Peplow]

Hi Darin.K,

Your top method in the code snippet has resolved my issue and I would never have thought of doing it like that. That is one for the memory banks so cheers!

Out of interest, you mentioned that I could make the cluster an object, however I have never used objects apart from when I sat the object-orientated training course. Were you inciting that I make this portion of code object-orientated or can you use the object in another way which I am unfamiliar with?

[Darin.K]

Turning your cluster into an object basically gives you a big rug to sweep things under.  At the deepest level an object is a cluster, so in this case the *real* differences would primarily be cosmetic.

You have two problems:  you have to get data into a cluster and then you have to be able to get data out.  The users getting data out are at the mercy of the actual data layout.  The layout which makes it easy to get data in may not be so nice when getting data out.  With LVOOP you can build in a little abstraction so the users do not see the underlying structure.

The underlying code is probably just as ugly with or without LVOOP, it is just that when you say "I used LVOOP" people reply "That's sweet".  When you do not use LVOOP they see the same code and go "What a mess."

You already TypeDef the clusters and get a sense of "there must be a better way" when you start doing the unbundle/bundle dance so those urges will serve you well and help you avoid many of the problems LVOOP is around to solve.

In short, I would be very hesistant to refactor working code from non-LVOOP to LVOOP.  But I would suggest you study up on it a little bit and when you have an opportunity in new code to take advantage of the things it does very well (dynamic dispatch) you take it.

[Mitch_Peplow]

I think that has to be one of the clearest explanations I've heard for some time and I'm sure many others will appreciate that explanation as well.

Putting LVOOP into action has long been at the top of my hit list, not only because it intrigues me so much as to the methodology and just how abstracted you can make things but also to see how it truly compares to the standard way of coding. Most developers I speak to seem to be very cautious about using it but do admit that when it works, its awesome!