Include "To More Specific" and "To More Generic" class casting inside the class terminal of a method.

[PrimaryKey]

Hello All, I find myself often writing duplicate code just to be able to filter out the objects I want to work with from a collection that has many.

Examples of that can be:

- sending message objects in queue,

- working with multi object type arrays,

- parsing large objects composed of smaller ones,

- and many more...

The duplicated code is almost always the same. It's trying to cast to more specific or more generic, catching the error in case structure and invoking the method im interested in. Being able to perform casting as a part of the teminal would solve the problem with no extra code on the diagram. In the background, the compiler can treat this the same way as cast+case but we wouldn't have to worry about that.

The option could be enabled whenever you try to wire an object in the same hierarchy that does not have that specific method you need, but it's on a different level in the hierarchy.

Please let me know what you think.

[Mythilt]

How would you pass on the cast error since a class method might not have an error out terminal and the programmer might want to handle an error with specific code.

[PrimaryKey]

You might want to limit the possibility to make the cast if there was no error out terminal on the method. In that situation the option would be grayed out. You might also want to require a specific connector pane and a specific location for the error out, before the option would become enabled.

[AristosQueue (NI)]

a) To More Generic is ALWAYS a no-op at run time. It's only purpose is to provide a way to remove the coercion dot. It doesn't change the execution of your code at all.

b) If you are having to do widespread type casting, that is almost always a sign that there is something severely wrong with your code, for two major reasons:

1. To More Specific is extremely poor performance when compared to dynamic dispatching. In all of the examples you discusss above, the first question to ask is, "Why haven't you created a method on the parent class and then overridden it in the children with their specific behaviors?"

2. If a method can accept a parent but not all the children, somewhere you have violated the Liskov Substitution Principle, probably in a major way. This makes all of the contracts that your classes have with their callers invalid, which generally means any refactoring is doomed.

In general, the code you are asking for is very bad code, and the fact that you have to go use the To More Specific node is a red flag. It is a necessary evil to get around limitations in the design of code -- sometimes we developers just don't think of everything when we do the original design, and sometimes we just don't have time to refactor -- but it is not something that should be enshrined in the G language as a "proper" thing to do.

[PrimaryKey]

This request basically comes from the inability to define interfaces in LV. If I had interfaces and could inherit from multiple, I would make a design that would satisfy you and not be "very bad". But since there are no interfaces I have to get by, and this is how I could. Generics would also solve my problem.

What if you have something which is both a wave and a particle. Sometimes you want to treat it as a wave and sometimes as a particle. Sometimes you want it to interfere with others and sometimes you want to count it. But in the mean time you still want to be able to convert energy into it in a generic way. There are levels at which it makes sense to add some totally new behavior. You can take also emergent properties as an example.

[AristosQueue (NI)]

In that case, close this as a duplicate and PLEASE join the chorus of voices begging for interfaces. I keep hoping that enough user pressure will get this to be a priority! 🙂

[crossrulz]

Just to complete AristosQueue's comments, here is the link to the idea for LVOOP Interfaces.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.