Jump to content

Norbert_B

NI
  • Posts

    4
  • Joined

  • Last visited

About Norbert_B

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2004

Norbert_B's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Thanks for your long answers, AQ. That really sets things in a better light I concur with most of your points and thanks for sharing the discussion about "atomic property nodes" when using classes/class DVRs. BUT: When talking about "atomic" (encapsulated and protected ranges of code i mean by that), LV does already provide good mechanisms, also with LV classes. Each VI is automatically locked as long as it isn't reentrant. So coupling my suggestion with classic OOP concepts, IF the developer of the class requires a couple of functions to be atomic, he has to create a "master function" calling into the collected subfunctions. Due to the "master function" being a single LV VI in LVOOP, we already got the lock! You are correct that this behavior (if NI was to provide it) would lead to issues for some users as they do not read, check out things and only rely on "their way how to do things". But this kind of customer is always an issue for a company, except you work on turn-key solutions for this specific customer.... I think that a good documentation and some good examples would be enough for most developer to understand pitfalls and to avoid them. I am confident that providing a "complete" by-reference handling of objects does not contradict the very basic paradigm of LV: dataflow programming. thanks again, (and hopefully, R&D re-discusses this ) Norbert
  2. Essentially, i refer very much to this idea on the NI Idea Exchange Forum: Have Dynamic Dispatching terminals accept Data Value references of the class or any child class Reading the comments, especially yours, AQ, you make valid points. True. But on the other hand, LV could provide a default behavior for handling object references in dynamic dispatching, naturally on a per-function-call-basis (speaking of locks). Why is that? I would expect this behavior to match the majority of use-cases if a LVOOP developer choses to use DVRs (by reference passing). And, the most important thing: This basic functionality (which is then incorporated) does not prohibit different approaches just as the stated exceptions like locking a set of functions (instead on a per-function-call basis) or passing the reference after possible modification instead of the original one as copy (as most examples you linked obviously do) are still implementable just like nowadays. You are correct that given the fact that depending on the language we have by reference vs. by value calls. And that LV provides BOTH approaches. What i do dislike is that the by reference way is very worksome and requires well defined wrappers for re-usability. Norbert
  3. James, you are correct. I took the example from the NI community page i linked in the post. Obviously, the page got removed, at least the link is not valid anymore. So i would expect the code also to be removed. Current examples for singletons look different, which really work as a singleton. Sorry for this confusion. Regarding polymorphism of OOP functions: Of course you are correct that one can use LV polymorphism to implement this. But this only works for class specific functions. So the "constructor" (Initialiize function) is a bad example for this. Therefore, i included feedback point 3.... Thanks for the reply, AQ. But i am honestly a little disappointed by it. As my inital post indicated, i am well aware that most of the points are already possible by using an overelaborate way of implementation. I wanted to pass feedback to LV OOP R&D for improving the status quo, not discussing possible "status quo approaches". Common OO-languages provide two approaches for flexible functions (like the constructor) which include enables the developer to work as easy as possible: a) Overloading: This enables a very specific setup of equally named functions in a class with a specifc set of parameters per implementation. So datatypes can be provided specifically. Overloading is incorporated in the language, hence creating a wrapper is not necessary. b) Using felxible datatypes: Most often, variants are used for this. Advantage: i have only a single function (unique name) which provides all parameters, mandatory or optional as required. Disadvantage: The caller, so the user, has to know how to unwrap the data for return values. ActiveX is very prominent example on this approach and i very much dislike it as you require additional documentation on the function prototypes on how to wrap/unwrap parameter data (which often lacks for APIs) In LVOOP, one can only work with manually implemented wrappers or by choosing different approaches for implementation. YES, you can do it, but this often seem overelaborate. Especially the necessity to write a wrapper for dynamic dispatching when using DVRs seems overelaborate as it is always the same approach. So it would be nice if LV itself would already handle this and supply the user with dynamic dispatching DVR terminals just like with class wires. Also, i know that not every suggestion is valuable for every programmer. These are just feedback points which i collected during discussion with different LVOOP users (or newcomers) which i find valuable as additional/modified functionality. Norbert
  4. Hi, following some suggestions for improvement of LVOOP which i'd like to see in LVOOP in a future version. Please note that all those questions refer to an architect level! 1. Constructor: LV enables the programmer to name a VI equally to the class the VI contains. So it is possible to generate a "constructor", even though we don't necessarily encourage the user to do so. See attached example for this. The idea is to create a "constructor" VI which creates an object and calls required initialization routines internally. An example would be configuring an instrument for a specific HAL class. An often used feature for such constructors is "overloading", so having different sets of parameters while keeping the same function name. Currently this is not supported in LV. What do you think about this feature when talking about constructor VIs as explained above? 2. Destructor: This is tricky since most OOP guys would expect this to destroy the object, which in case of LV is obviously most often not the case. Still, it could be used for de-initialization for the user of the class. See attached example for this. 3. Polymorphism/Inheritance: In some cases of OOP, it would be beneficial to have polymorphism for class functions, sometimes directly connected to inheritance. Small example: Class "DataAcquisition" defines general IO functions. Class "AI" inherits from DataAcquisition, overriding all AI functions. Polymorphism should be used for DataOut since Data could be a waveform, a 2D array, .... Additionally, polymorphism could be used for inheritance directly if parameter types depend on the specific class. E.g. aggregation collects different class objects. 4. Singleton: One can create a singleton as seen in attached example or on https://decibel.ni.com/content/docs/DOC-13462. The problem i got with this singleton pattern is that the object within the DVR (the singleton) cannot be used for dispatching, hence no inheritance override possible. In order to get this to work would require the following change: The connector pane terminal of type "LV Object" and "DVR to LV Object" shall be configurable to "Dynamic Dispatch Input (Required)". Currently, this option is only working for "LV Object". 5. Overloading: As already stated in point 1., overloading would be a nice feature for constructor VIs. Adding to that, overloading could be a nice feature for inheritance as well. So the override function can add (not remove!) additional parameters without the need to define a generic data container (e.g. variant) in the ancestor class.   I know that all features, except 4. Singleton, can be solved differently, best done by appropriate wrappers. But i think that some developers could profit from LV opening up to more a common OOP approach used by other OOP languages. @NI R&D: If some of these are already on schedule, please let me know @All: Please discuss! thanks, Norbert Singleton.zip ClassConstructor_Destructor.zip
×
×
  • Create New...

Important Information

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