LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
smmarlow

Dot Notation for Method VI names in LVOOP that is similar to GOOP

Status: Declined

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

Okay, so I am not really convinced myself if this is a good idea or not, or perhaps it has been discussed before and heavily flamed. It might be helpful if the LabVIEW class dynamic dispatching paradigm would recognize the GOOP-style naming convention for child class methods. If LabVIEW ignored all except the last two sections of dot-notation filenames (only for the purpose of dynamic dispatching!), then the GOOP-style naming convention could be used for child methods.  This could reduce the risk of heavy LVOOP users potentially having thousands of different files in their code repositories with the same name, like "Initialize.vi","Configure.vi","Create.vi","Destroy.vi", "Close.vi", etc.  It would also not upset the current paradigm for those who don't use the GOOP naming convention.

 

Current:  

 

Filenames must be the same for dynamic dispatching.

In this example, PXI and cRIO are descendants of DAQ.

 

DAQ.lvclass:

Initialize.vi

Acquire.vi

Close.vi 

 

PXI.lvclass:

Initialize.vi

Acquire.vi

Close.vi 

 

cRIO.lvclass:

Initialize.vi

Acquire.vi

Close.vi 

 

Proposed:

 

Only the final two sections of a dot-notation name are compared for

dynamic dispatching (sections shown in magenta are ignored).  

 

Allows for GOOP-style filenames by those who wish to use them,

but will not disturb the current paradigm

 

DAQ.lvclass:

DAQ.Initialize.vi

DAQ.Acquire.vi

DAQ.Close.vi 

 

DAQ.PXI.lvclass:

DAQ.PXI.Initialize.vi

DAQ.PXI.Acquire.vi

DAQ.PXI.Close.vi 

 

DAQ.cRIO.lvclass:

DAQ.cRIO.Initialize.vi

DAQ.cRIO.Acquire.vi

DAQ.cRIO.Close.vi 

7 Comments
Darren
Proven Zealot
Status changed to: Declined

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

TomOrr0W
Member

If I had noticed this idea before it was auto-declined, I would have Kudo'd it.

 

One nice thing about doing things this way would be a reduction in the number of file name collision warnings when building an application (I am relying on memory here.  It has been a while since I have paid attention to those warnings when building an application, so it is possible they already won't occur in a dynamic dispatch situation or in newer versions of LabVIEW).

crossrulz
Knight of NI

TomOrrOw,

The file name collisions when building an application will only happen if you build in a LabVIEW 8.X format, which is a flat directory.  2009+ uses a zip-like format, which will avoid the file name collisions.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Intaris
Proven Zealot

I don't like this idea at all.

 

If we change the inheritance of a module (like adding a grandparent for abstracting out some functionality) then we need to rename ALL children to include the name?  And then if we remove it later due to refactoring, again rename ALL VIs?

 

My SVN server is cursing me at the thought of it.

 

Not to mention, what if the class name has a "." in it?

TomOrr0W
Member

I didn't think about the inheritance/name change issue.  Allowing this would probably create a larger issue in version control than the feature is worth.

Since the file name collisions are no longer a thing, and the idea has some significant downsides - I swear I remember seeing this more recently than LabVIEW 2009 (I don't remember ever checking the use 8.x format option), I would probably revoke kudos at this point if it were still open.

As a side note, the class name having a "." in it would be fine in the idea as written.  The actual file name that needs to be the same would be between the second-to-last period and the end of the file name.  This would only be an issue if you wanted the method name to have a period in it - unless it was implemented with some sort of core name property that needs to be checked, in which case, you would only check for that exact string and an extension.

AristosQueue (NI)
NI Employee (retired)

Fixing the "dotted names hack" was one of the goals of LabVIEW classes. We won't be going back to that.

smmarlow
Member

Egads!  I forgot this even existed.  Kinda funny that it was posted over seven years ago and it's just now getting comments.  Even I think it's a bad idea now.