Jump to content

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


Recommended Posts

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?

Link to comment

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).

Link to comment

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.

Link to comment

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

> 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 :shifty:

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

Cheers,

-Jim

Link to comment

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

Link to comment

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

Link to comment

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

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.