Class Property Nodes confusion

[bsvingen]

I am wondering if they are correctly implemented, and if so will they stay this way.

For instance, all descendant classes can use the properties of the ancestor class with no implementation whatsoever of the read/write vi's of the descendant classes. The other thing is that I can add code into the class property node, making it a sort of strange invoke node.

Regards

[SteveChandler]

I think the point of class property nodes is intended to replace read/write vis. They are kind of a strange invoke node. I would think that they will stay just like they are since changing this would break lots of peoples code.

[Mr Mike]

I am wondering if they are correctly implemented, and if so will they stay this way.

For instance, all descendant classes can use the properties of the ancestor class with no implementation whatsoever of the read/write vi's of the descendant classes. The other thing is that I can add code into the class property node, making it a sort of strange invoke node.

Regards

These are both as intended. In all the object oriented languages I know child classes automatically inherit parent methods and properties.

And yes, you can add code to a property node to make it have a side effect, but that's probably poor programming practice (alliteration for the win!) . The intent of being able to add your own code is to make properties for class members which don't exist. Suppose you had two pieces of class member data named "Number of Front Wheels" and "Number of Back Wheels." You wouldn't want a third called "Number of Wheels" because you'd need to update it when you updated either of the first two. You can create a "Number of Wheels" property which adds the two and returns the sum (in addition to properties for two members). You can also add code to add some sort of caching behavior. In general, LabVIEW Class properties work a lot like C# class properties.

[bsvingen]

These are both as intended. In all the object oriented languages I know child classes automatically inherit parent methods and properties.

And yes, you can add code to a property node to make it have a side effect, but that's probably poor programming practice (alliteration for the win!) . The intent of being able to add your own code is to make properties for class members which don't exist. Suppose you had two pieces of class member data named "Number of Front Wheels" and "Number of Back Wheels." You wouldn't want a third called "Number of Wheels" because you'd need to update it when you updated either of the first two. You can create a "Number of Wheels" property which adds the two and returns the sum (in addition to properties for two members). You can also add code to add some sort of caching behavior. In general, LabVIEW Class properties work a lot like C# class properties.

OK, sounds good to me. With "ordinary" LVOOP I have to make dynamic dispatch vi's to be able to use get-set methods of data for the parents, (that's what I have been doing) . With these property nodes there are no longer any need to do that. Will this property node be faster execution vise than equivalent dynamic dispatch, or is it simply a dynamic dispatch (with all the overhead) in disguise?

[Mr Mike]

Will this property node be faster execution vise than equivalent dynamic dispatch, or is it simply a dynamic dispatch (with all the overhead) in disguise?

It's dynamic or static dispatch in disguise. If you set the object connector pane terminals to static (i.e. the class in is Required and class out is Recommended or Optional), then it will function as a normal subVI call. If you set them to Dynamic, then you'll have dynamic dispatch behavior. The overhead for a dynamic dispatch call isn't actually that high, so don't concern yourself too much with that.

LabVIEW Class Properties are essentially syntactic sugar. They don't give you anything you couldn't do with subvis and case structures (for error handling).