Type Specialization Structure case order

[JÞB]

Is there an optimal or recommended order for cases in a TSS?

For instance, should we handle all Integers before Floats?  All fixed width datatypes before Strings? Etc...

What are your guidelines and experiences?

[raphschru]

I usually implement the most likely data type in the first case. Generally, this is also the default type of the malleable input. Then, next cases are other types in descending order of probability.

By "optimal" it depends in what terms you are asking, but here are my insights:

Runtime performance: not affected because the case is fixed before compilation.

Editor responsiveness: I guess if you wire a type implemented in 1st or in 50th position in your TSS, it can make a difference. I suppose it loops through every case until one compiles, so having most likely types first gives you a general responsiveness optimization.

Diagram readability: Putting most likely types first also tells other developers for which type your VIM is mostly useful.

Regards,

Raphaël.

[altenbach]

You might run into a situation where some type specialization cases will result in unbroken code for multiple input types, but some of these types require special handling. You should probably order the cases from most specific to most general.

For example, you might have one case where data is just wired across and thus will never be broken. If that case would be placed first, the other cases would never be tested.

[JÞB]

Let me give a specific example of a vim that I think would be useful.   Remove duplicates from 1D Array.vim implemented as:

• Reverse 1D Array
• For each element; cast to string, write attribute of VOID Variant / Map [String: i]
• Read all attributes 
• For each attribute; bundle <value, Name> 
• Sort Cluster array
• Reverse Cluster Array 
• For each Cluster Array element; unbundle String and cast to input Array datatype.

That works for most datatypes but would need a TSS for refnums to break the vim caller and Boolean,array would be better served with build Array of And array,Or Array plus an array of And array negated, Or Array driving a codeless For loop with a conditional tunnel. Plus a search 1D Array for Tthen, if index=0 reverse the output Array ( there are 4 possible outputs: [T , F], [F , T], [F], [T])

OK probably not the best example 🙄 because it works for everything except refnums.  But, suppose I did need 50 TSS cases, what are the known caveats and best practices each of you have?

[altenbach]

What's wrong wit the one we already have in the array palette?

[JÞB]

---

@altenbach wrote:

What's wrong wit the one we already have in the array palette?

---

Well, it's F'd for refnums. 😮  what is in the enabled case?

For safety, it really should break the caller if the datatype is refnum or a Map / Library / Cluster containing a refnum or a variant with a refnum attribute. 

[altenbach]

The enabled case is empty, of course. It just creates an empty set of the correct datatype using the "use default if unwired" output tunnel.

(Sorry, I am not familiar with the refnum, etc. concerns)

[JÞB]

Two references are equal if they refer to the same thing regardless of the integer value.  That code will not remove refnums that pass an Is Equal? Comparison to another refnum in the Array. 

So, it provides unexpected behavior for arrays of queues, user Events, notifiers etc...

Now back to the OP topic.

[paul_a_cardinale]

---

@JÞB wrote:

Two references are equal if they refer to the same thing regardless of the integer value.  That code will not remove refnums that pass an Is Equal? Comparison to another refnum in the Array. 

So, it provides unexpected behavior for arrays of queues, user Events, notifiers etc...

Now back to the OP topic.

---

Starting sometime around LV 2008, comparison functions were made smarter regarding references.  When the "Equal?" function compares two references, it returns TRUE if they refer to the same object, regardless of their numeric values.  Also works with functions like "Search 1D Array".

[altenbach]

Thanks. well, I don't do these comparisons anyway. 😄