I want polymorphic support for arrays in To More Generic/Specific

[Jim Kring]

One thing that I would like is support for arrays in the To More Generic Class and To More Specific Class functions.

For example, if I have an array of Lines, then in order to convert them to an array of Graphics (Lines are Graphics) I have to use the To More Generic Class function inside a For Loop (as shown below), since the function does not support arrays.

http://forums.lavag.org/index.php?act=attach&type=post&id=6641

What I really want to do, is omit the For Loop and have the To More Generic Class function adapt to the array. But, it doesn't, as you can see in the screenshot below.

http://forums.lavag.org/index.php?act=attach&type=post&id=6642

Additionally, To More Specific Class could benefit from support for arrays, but with an important consideration: it has an error output. Unlike To More Generic Class which detects type errors at edit time, To More Specific Class detects type errors at run time. And, since this function can generate an error, it might be ambiguous as to which element of the input array generated the error. There are basically two behaviors that one might desire:

1) Make the error output an array (as shown below).

http://forums.lavag.org/index.php?act=attach&type=post&id=6643

2) Make the error output a scalar an stop iterating over input elements when an error is raised (as shown below).

http://forums.lavag.org/index.php?act=attach&type=post&id=6644

Perhaps the user could chose between these two behaviors via a right-click option on the nodes. Or, if that's too much work, maybe behavior #2 would be standard and the user could then call Merge Errors explicitly to convert the error cluster array into a scalar (as shown below).

http://forums.lavag.org/index.php?act=attach&type=post&id=6645

NOTE: There are other functions that could benefit from added support for arrays. For example, how about Close Reference?

[crelf]

QUOTE(Jim Kring @ Aug 17 2007, 03:24 AM)

One thing that I would like is support for arrays in the To More Generic Class and To More Specific Class functions.

Seconded. (not just in the LVOOP context - I'd like to see this everywhere in LabVIEW. eg: if I have an array of numerics that I want to make more/less generic, I'd rather not have to do that in a loop as Jim showed).

[orko]

QUOTE(Jim Kring @ Aug 16 2007, 10:24 AM)

NOTE: There are other functions that could benefit from added support for arrays. For example, how about Close Reference?

How about property and invoke nodes?? Like....

http://forums.lavag.org/index.php?act=attach&type=post&id=6648''>http://forums.lavag.org/index.php?act=attach&type=post&id=6648'>http://forums.lavag.org/index.php?act=attach&type=post&id=6648

[Aristos Queue]

You want a primitive (or property node or other LV node) with different behavior than the current primitive.

But you have many different configurations that you'd like the new prim to support.

And you might have other modes that you might want for particular cases, so the uses are a bit open ended.

And you've already written the VIs that would do exactly what you want.

But Create SubVI doesn't work because that causes the data types to be fixed.

May I suggest that what you really want is polymorphic tunnels on subVIs? Enhancing a single prim is fine, but this is exactly the kind of request that makes me want to find a better solution language-wise.

But I'll pass your suggestion along to the folks that own these primitives.

[wevanarsdale]

QUOTE(Jim Kring @ Aug 16 2007, 01:24 PM)

NOTE: There are other functions that could benefit from added support for arrays. For example, how about Close Reference?

I believe Close Reference supports arrays in LabVIEW 8.5.

[orko]

QUOTE(wevanarsdale @ Aug 16 2007, 11:26 AM)

I believe Close Reference supports arrays in LabVIEW 8.5.

Hey, yes it does!

[Jim Kring]

QUOTE(Aristos Queue @ Aug 16 2007, 11:25 AM)

You want a primitive (or property node or other LV node) with different behavior than the current primitive.

But you have many different configurations that you'd like the new prim to support.

And you might have other modes that you might want for particular cases, so the uses are a bit open ended.

And you've already written the VIs that would do exactly what you want.

But Create SubVI doesn't work because that causes the data types to be fixed.

May I suggest that what you really want is polymorphic tunnels on subVIs? Enhancing a single prim is fine, but this is exactly the kind of request that makes me want to find a better solution language-wise.

But I'll pass your suggestion along to the folks that own these primitives.

> May I suggest that what you really want is polymorphic tunnels on subVIs?

YES! YES! YES! YES! YES! YES!

I've wanted the typeless (polymorphic -- edit-time type propagating) control/indicator for years! I've got a million things I want to do with this! It's one of the (undiscovered) pillars of LabVIEW code reuse! Expect to see a whole wave of new OpenG VIs follow suite.

> But I'll pass your suggestion along to the folks that own these primitives.

Thanks. I won't say no to that, either

QUOTE(wevanarsdale @ Aug 16 2007, 11:26 AM)

I believe

Close Reference

supports arrays in LabVIEW 8.5.

That's great!

I also noticed that there's a green VI in the palette that also supports arrays

http://forums.lavag.org/index.php?act=attach&type=post&id=6653

Cheers,

-Jim

[MikaelH]

When you talk about casting to more specific, I like to add a wish of Type Cast for LV objects.

Maybe this is impossible for LabVIEW to support due to its OO design, but what I'm after is to convert an object of one type to another sub class type.

E.g. First create a Graphic object and then Convert it to a Line Object.

Like this:

Line MyNewLine = (Line) MyGraphicObject

Why would I like this?

I use this method right now (using the Endevo GOOP Inheritance toolkit) when cloning an object.

In this example I would like to do this:

Class ClassNode{   …   Public Clone()   {	  ClassNode MyClonedObject= (ClassNode) super.clone();	  …	  return MyClonedObject;   }   …

http://forums.lavag.org/index.php?act=attach&type=post&id=6657

//Mikael

[Aristos Queue]

QUOTE(MikaelH @ Aug 16 2007, 05:20 PM)

Maybe this is impossible for LabVIEW to support due to its OO design, but what I'm after is to convert an object of one type to another sub class type.

You mean like this?

http://forums.lavag.org/index.php?act=attach&type=post&id=6658''>http://forums.lavag.org/index.php?act=attach&type=post&id=6658'>http://forums.lavag.org/index.php?act=attach&type=post&id=6658

[MikaelH]

Thanks Stephen.

Yes that will work and solves my Clone use case, but you're not actually converting the ParentClass Data wire to a Child data wire.

But maybe this is not needed, but it could look like this.

http://forums.lavag.org/index.php?act=attach&type=post&id=6662

Here is also another clone project:

http://forums.lavag.org/index.php?act=attach&type=post&id=6663

Thanks

//Mikael

[Aristos Queue]

QUOTE(MikaelH @ Aug 16 2007, 10:47 PM)

it could look like this.

http://forums.lavag.org/index.php?act=attach&type=post&id=6662''>http://forums.lavag.org/index.php?act=attach&type=post&id=6662'>http://forums.lavag.org/index.php?act=attach&type=post&id=6662

I think it is fairly awkward to call that a cast. When I cast from 8bit integer to 16bit integer, I don't create any new information, I just rearrange the info that is there. The same is true with casting a string to an array of bytes. When casting a parent to a child, you really are creating information ex nihilo.

For LV to offer a primitive that does this sort of casting for an arbitrary class would be a complete violation of encapsulation. Suppose that the parent allows you to set values in the range 1-10. The Child class overrides the SetValue method and constrains the value to be 1-5. A user could construct a parent class with a value of 10 and then force construct that as a child, resulting in an invalid child class.

Neither C++ nor Java allows you to cast a value of the parent class as a child class. I don't know of any that allow this sort of thing. You can, as I did in my VIs, construct/initialize a child from a parent, if the particular parent/child relationship finds that to be appropriate. But a generic cast of this sort would be a very bad thing for any OO language to support. Languages do exist that allow you to cast a *reference to parent* as a *reference to child*. That's a very very different thing.

Let me go one step further and say that in the vast majority of cases where you might think you want this ability, you've actually got the wrong relationship between the classes. Instead of inheritance, you should have containment. The "child" class should actually contain as a private data member an instance of "parent" instead of one inheriting from the other. Thus the parent data gets constructed at time N and at time N+1 the child data gets constructed with that parent data as a data member.

[MikaelH]

Your right, I'm always thinking in reference based objects

In java it look like like: SubClass MyClonedObject= (SubClass ) super.clone();

Also I prefer protected attributes, when will that be available ;-)

http://forums.lavag.org/index.php?act=attach&type=post&id=6666

//Mikael

[i2dx]

QUOTE(Jim Kring @ Aug 16 2007, 11:02 PM)

I've wanted the typeless (polymorphic -- edit-time type propagating) control/indicator for years!

... plus the typleless wire, plus a primitive to detect the data type or something like a case structure that detects the wire type. This would make it possible to create a polymorphic VI INSIDE one single VI, without the hassle to create many VIs and bundle them to a polymorphic VI. Ok, that would make the current way of creating polymorphic VIs more or less dispensable for simple data types and arrays of simple data types. It would be of course a problem with more complicated datatypes, like clusters, etc ..., but IMHO it would not be to difficult to give us this feature for simple datatypes and arrays of simple datatypes and leaving the complicated stuff for the next generation of skilled LV developerts

http://forums.lavag.org/index.php?act=attach&type=post&id=6667

QUOTE(Jim Kring @ Aug 16 2007, 11:02 PM)

I've got a million things I want to do with this! It's one of the (undiscovered) pillars of LabVIEW code reuse!

/signed

[Tomi Maila]

I strongly disagree with Jim's original suggestion of changing the functionality of typecasting primitive. Consider a future in which all LabVIEW primitive types would be actually build-in classes, and would behave as such. Then an array would also be a class type by itself. Now if we change the behaviour of casting nodes for arrays, these nodes would behave an incorrect way when arrays would be classes by themselves.

So the correct way to do this is to make arrays classes them selves and modify the cast operation so that

to_more_generic(My Specific Array, array(Generic Class))

would return an array of type Generic Class.

[crelf]

QUOTE(Aristos Queue @ Aug 17 2007, 04:25 AM)

May I suggest that what you really want is polymorphic tunnels on subVIs?

DING DING DING - We have a winner! That's exactly what I want!

QUOTE(i2dx @ Aug 17 2007, 04:09 PM)

...a primitive to detect the data type or something like a case structure that detects the wire type.

:thumbup: