Why can't I create property definition folders on an interface?

[Yamaeda]

---

@thols wrote:

---

@Yamaeda wrote:

---

@UliB wrote:

---

@Yamaeda wrote:

The only thing i dislike is the full classname incl. the .lvclass in the head taking up much space. 

---

Open Class Properties -> Documentation Page and change the Localized Name as you wish.

---

Thanks! Didn't know that!

---

You can also make a script that does that on all classes. For example the G# add on sets the shorter name when creating a class (see Yamaedas GitHub link).

---

Does it? Maybe it's just this project that's old and inherited. 🙂

[thols]

---

@Yamaeda wrote:

---

@thols wrote:

---

@Yamaeda wrote:

---

@UliB wrote:

---

@Yamaeda wrote:

The only thing i dislike is the full classname incl. the .lvclass in the head taking up much space. 

---

Open Class Properties -> Documentation Page and change the Localized Name as you wish.

---

Thanks! Didn't know that!

---

You can also make a script that does that on all classes. For example the G# add on sets the shorter name when creating a class (see Yamaedas GitHub link).

---

Does it? Maybe it's just this project that's old and inherited. 🙂

---

Yes it does, since like 2012 or something when the feature came out: 

But it would be nice to have a script that does it on all existing classes. Should be simple to make.

[Quiztus2]

Imagine 2 interfaces having getImage defined and both being inherited by the same class. From the top of my head I don't know if LV could handle that.

Furthermore, I remember with multiple inheritance that the class has to implement all methods. So if the class doesn't hold the property in question, that would be not so nice. 

Until now I cast the interface to the type, I know is holding the desired property. Which seemed OK to me.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-default-localized-name-for-objects/idi-p/22978...

[TimBlaisdell]

---

@Quiztus2 wrote:

Imagine 2 interfaces having getImage defined and both being inherited by the same class.

---

The same thing could be said about regular methods, which LabVIEW supports.  

In other languages (e.g. C++), if a class inherits from two interfaces that both define the same property or method (with identical arguments), then the class can have just one definition for the property or method that will satisfy both.  If it's a method and the two have different arguments, the class can define two overloads to satisfy it.  LabVIEW doesn't support this, so I don't know what it will do.

[BertMcMahan]

IIRC, if a class has a method defined with the same name as an interface, it will default to using the one defined by the class itself. If it has two interfaces with the same method, you get a broken wire and must explicitly cast the object to the correct interface before it will let you call that method.

[Quiztus2]

I think me personally wouldn't start adding accessors into my interfaces in the future. In my opinion interfaces should be lean and reflect only behaviour. From the practical point multiple inheritance could get messy more easily with a growing number of methods.

 However, LV should give developer the freedom to choose by themselves. if they want property def folder in Interfaces, they should be able to so.

[BertMcMahan]

---

@Quiztus2 wrote:

I think me personally wouldn't start adding accessors into my interfaces in the future. In my opinion interfaces should be lean and reflect only behaviour. From the practical point multiple inheritance could get messy more easily with a growing number of methods.

 However, LV should give developer the freedom to choose by themselves. if they want property def folder in Interfaces, they should be able to so.

---

IMHO there are very frequently times when you need "behaviors" implemented at the Interface level.

Take a HAL that abstracts a voltage measurement device- "get serial number" or "get calibration date" would be something that all of your devices (might) need to implement.

Also, "read voltage" (the obvious "interface" method) may be nice to have implemented as a property node, which must be done using property definition folders.

[Quiztus2]

---

---

IMHO there are very frequently times when you need "behaviors" implemented at the Interface level.

---

you meant "accessors", not "behaviors" right?

Disclaimer: This is my very personal opinion and no advice!

calibration date and serial number properties belong into an intrument or configuration class.
read voltage belongs into the interface.

otherwise, consistency would lead to having get serial number in every behaviour the instrument implements.

E.g. an interface for: "read voltage" "triggered read voltage" "syncronized read voltage" "triggerable" or whatever ....

And this is perfectly fine, since you can simply cast the interface to the .lvclass, containing the getters, when you need them.

[BertMcMahan]

---

@Quiztus2 wrote:

---

---

IMHO there are very frequently times when you need "behaviors" implemented at the Interface level.

---

you meant "accessors", not "behaviors" right?

Disclaimer: This is my very personal opinion and no advice!

calibration date and serial number properties belong into an intrument or configuration class.
read voltage belongs into the interface.

otherwise, consistency would lead to having get serial number in every behaviour the instrument implements.

E.g. an interface for: "read voltage" "triggered read voltage" "syncronized read voltage" "triggerable" or whatever ....

And this is perfectly fine, since you can simply cast the interface to the .lvclass, containing the getters, when you need them.

---

Yes, sorry- "accessors" not behaviors.

So if the program that uses the device needs to record the device's cal date or serial number or whatever, it would need to cast the interface to the specific type. Doesn't that defeat the whole point of the interface? I don't want my HAL's knowing anything about the specific instrument classes- for one, it would statically link my "thing using the HAL" to every specific class, which is something I can avoid with interfaces.

I do see your point though. In the case of multiple behaviors, I think I'd have a separate "instrument" interface that provides all of the generic stuff as well as the "behavior" based interfaces you're talking about.

[TimBlaisdell]

Hey everyone, thank you for all the interesting and thoughful responses here.

As someone who was trained as a software engineer using C++ and similar OO languages, the idea that "behaviors" (i.e.. methods) and properties can be defined at the interface (fully abstracted) level is fundamental to OO design.

For example, suppose you have an interface like "Vehicle".  You could define methods like "Accelerate", "Brake", etc., and you might have properties like "PassengerCapacity", "MaxSpeed", "FuelLevel", "TurningRadius", etc. (just making things up here).

Exactly how any specific vehicle implements the methods will of course differ greatly for a "Bicycle" vs. a "Lamborghini".  Also, how the values of various properties will be computed or measured might differ greatly.  

By defining an interface, what you are doing as a software designer is like writing a contract, saying to all future developers (including your future self) "these are the basic things that something must implement to be defined as a Vehicle, and used as a Vehicle within this software system".

Just to head off one of the typical responses I've heard... 

It doesn't make any sense to make "Vehicle" an abstract class, because there's literally no meaningful "default implementation" for any of the properties or methods when a "Vehicle" could be anything from a tricycle to a  Boeing 787.  In the LabVIEW world, you'd have to write a slew of VIs in the base class that return meaningless constants (zero or whatever) and then require that derived classes override the default implementations for everything.  Why pretend to support "interfaces" if you're going to require that?