Leaderboard

This thread got me to reorganize my workspace and project structure to most importantly improve load and build times and reuse workflow. It came to me as a surprise that LVLIB's although great in some ways force static links to everything in the library. I had previously seen this with classes but for some reason didn't expect the same from LVLIB's. Anyway, I ended up breaking apart a lot of reuse code and restructuring a large project. This seemed obviously a pretty daunting task at first and I was looking to utilize the "links" application by JackDunaway/Wirelabs. Unfortunately, I didn't manage to get it working fully so what I ended up doing was grabbing the hidden "App.Read Linker Info From File" invoke node from the code and searching the list for items where links jump to unintended libraries etc. The few hours of work were definitely worth it and I can recommend similar procedure to anyone starting to see the effects of unwanted coupling.

No, the other way around. Let's say you have some data that passes through a dynamic dispatch VI (that is, there is an input and a corresponding output of the same type). The parent method passes the data through unchanged, so LabVIEW expects that it can reuse the input buffer for the output buffer. Now you override that method in a child, and you do modify the data. At compile time, LabVIEW uses the parent class (it can't know about all the possible child overrides) to determine whether it can expect to reuse the buffer. At runtime, when the child class runs, LabVIEW discovers that it needs to create a copy (to accommodate the modified data) and so it needs to allocate an additional buffer. Now, if instead you put an in-place element structure in the parent, and marked the terminal as a modifier, at compile time LabVIEW will pre-allocate a buffer for the output, even though it's not necessary in the parent, which will allow the child that modifies the data to execute a tiny bit faster. I'm not sure why this would ever be a useful option for a DVR.

http://zone.ni.com/reference/en-XX/help/371361H-01/glang/in_place_element_structure/ If I remember what aristos told me about the lvoop comment, the mark as modifier would really only do anything for dynamic dispatch. He said something about how if the parent class just passes the data through without modification but you know most children will modify the data, this cues the compiler to know hey, you're going to need a copy of this data you can't pretend this section of code is read-only. With a DVR, you always lock the value and I would assume operate in place, so I can't imagine why this would do anything for DVRs. Edit: lol Also on the original DVR subject, aristos' comments here may also help: https://decibel.ni.com/content/docs/DOC-40468

It's tenable at worst, desirable at best, for an LVCLASS and its members to be statically-linked. Any desire otherwise could be an indicator of class design or object model that could use refactoring, or a desire for more appropriate language facilities (more on that later). For an illustrated example, here's one annotated section of the diagram above: The top arrow shows methods from a third-party hardware driver that are required by the application, the middle arrow is very likely an LVCLASS or LVLIB, and the bottom arrow shows unreachable, unused dependencies -- portions of the hardware API that bloat the application. Although not ideal, this scenario of roughly ~30 unused source files may not be measurably bad. The birds-eye view of this application indicates ROI of refactoring this class probably isn't justified. Though, used in another application, that exact same library could cause problems (such as even further unwanted linkages, perhaps even some that break the application with unsatisfied dependencies such as uninstalled packages or platform-specificity). Different application space yields different polarizing filters through which we choose tradeoffs. As library designers, it's worthwhile to consider our responsibility to enable our developer-end-users, and explicitly avoiding designs which cause them heartache. -- I wasn't going to bring up Inheritance as another type of static linkage best cut with our figurative link scissors, but it's now relevant in the context of LVOOP. Inheritance, in and of itself in any language, represents a code smell worth investigating. But... Inheritance! Dynamic Dispatch! This example demonstrates precisely the value of traits/mixins in an OOP language. With traits/mixins, we can achieve all desirable outcomes discussed above in terms of higher cohesion and looser coupling (and re-use!), by eschewing 1) suboptimal/incorrect inheritance hierarchies, and 2) classes that do too much, even if there appears "good reason" for the monolithic library (Hardware APIs for LabVIEW are notorious for wrapping serial protocols as one-command-per-VI in monolithic libraries. There are thoughts/considerations of dynamic versus static programming as another solution, but that's another thread). Lacking Mixins in LVOOP, Inheritance sometimes is workably sufficient to describe and implement the real-world, but oftentimes it can't. Again, to be fair, it's healthier to focus on measurable negative value than pedantry, and oftentimes it's workable to incur these tradeoffs introduced by inheritance. @ShaunR, for this reason, I don't think LVCLASSes fall short in the way you might be describing. (Except for one debatable behavior in the IDE, where all classes in a hierarchy are broken if one is, and where the explanation as to why in that link is tenuous, where the more desirable behavior is to throw run-time exception in the scenario presented in that link) The way that LVCLASSes fall short is by lacking Mixins, which provide targeted and precise linkages to atomic units of relevant code. (for clarity, regardless whether industry is landing on the term Trait or Mixin, I support the construct that also provides extension of mutable state, not just method implementations, and certainly not just interfaces with no implementations. I think "Mixin" is most appropriate, its distinction from "Trait" being "Trait" might not connote further extension of state) tl;dr The design goal when designing an LVOOP object model is not necessarily to avoid all static links, but rather to intentionally design dependency vectors, especially recognizing and avoiding anomalies and incidental linkages that have detectable negative value. And, LVOOP needs Mixins.

RT @sreelathas: Build a REST API For Your #IoT Data Using #mongodb @NodeRED , and #IBM #Bluemix #InternetOfThings http://t.co/5eCmjevQ3Y