Jump to content

non-dynamic dispatch parent child VI name conflict


soupy

Recommended Posts

so everyone knows that a parent and child class cannot have VIs of the same name unless they are dynamic dispatch. The compile will fail if you violate this. so, my question is, why is this restricted? Is there a technical reason that this can't be done?

 

I ask this because i am working on a set of configuration file classes that are written directly to file. To deal with non-trivial permutations, i'm following the recommendations here (http://thinkinging.com/2007/04/14/supporting-multiple-versions-of-a-file-format/) and including a revision number in every class, subclass and child class. Because of the above naming limitation, i'm going to have to dance around naming conflicts since every class will be responsible for upgrading itself to its latest revision and will have similar functions. (e.g. ideally every class could have a function called Upgrade1To2.vi to upgrade from revision 1 -->2)

 

additionally, i'm pushing our team to use standard file naming terms and increase the modularity of our code via private methods, so I'm afraid that we're going to run into this issue more and more often.

 

I understand that it could be non-obvious that you aren't dispatching to the child method. Maybe you could explicitly acknowledge this? Maybe it could be allowed if it were made private since private methods cannot be dispatched?

 

You think this is good enough for the idea exchange? Anyone else find this useful?

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