Aristos Queue

Is that true in the recent versions? The typedefs got revision protection in LV 2015, I think. If the mutation is going to throw away data, it does the same sort of "relink" behavior as when changing conpanes of subVI so you preserve the data.

Short answer: Make it table driven. Long answer: As you scale up like that, you're entering the realm where you aren't going to code those values directly into G. You may be looking at an array of values in G that you loop over to create objects a binary file where you read back the objects you serialized earlier or something as complex as a SQL database with relationships between multiple tables and you process the entire database to create your object layout. These are just suggestions. There are many other options. The point is, you need to make your construction more data-driven instead of directly coded. This is true of all programming languages I've seen, not just G. The notation of objects is such that they come into being as data drives their existence. It's relatively easy to create an object with a given value, and if you're building up objects as they come into existence within a system, everything works fine. But to create an entire system of objects in one burst, you need a data structure that can describe an entire system. That's why things such as object databases exist.

The preference to use init methods instead of non-default class constants is so strong, LabVIEW NXG is planning to never support the feature. Any class constant there will always have only the class’ default value.

Definitely a bug. If you can share the code, it's worth escalating to an AE at NI to see if it is still broken.

I agree with Shaun. By the time you ship, of course, you shouldn't care whether auto error handling is on or off (your VI Analyzer tests caught those), but it is invaluable during early development. And if you did miss something (developer submitted a VI late on deadline and didn't quite follow procedure or test machine had a bad day and skipped a step of your build or whatever), having AEH enabled can save you a wealth of time.

So I have this bug report that AppBuilder fails to build this one particular app whenever the "remove polyVIs and typedefs" option is enabled. The top-level VI breaks during the build. I try some of our usual debug approaches and don't find anything, so I hack up AppBuilder a bit so that when I get to the end of the build, I can open up the broken VIs and see what they look like. And I see this: Where the heck have all the class methods gone? They're in memory at the start, missing at the end. That shouldn't happen! So I set up a trap to detect when the VIs go missing. I'm working in a debug build of LV with a lot of extra guards and logging turned on, so it takes about two hours to run this build. And I get nothing. So I rework my trap, thinking I've coded something wrong. Four times I do this over the course of yesterday, working on other issues while the build runs. Four times -- roughly 8 hours -- nothing. The VIs swear they're all in memory and the caller should know about them. This morning I come in and, for some reason, I happen to double-click on one of those ? nodes. And, lo, the missing VI opens. Say what? Turns out, AppBuilder had stripped all the VI icons out (saves space in the built EXE to ditch all those unneeded images), so they all render as the ? icon. I have no idea what's actually broken, but it ain't that all the class methods have gone away. One wasted day. *head bang* *head bang* *head bang* Yet another reminder -- as if I needed it -- that computers only do what we tell them to do. And they do it very precisely.

I decided my previous reply could be taken too snarkily... not what I intended. Let me be explain -- Ernesto is right, and with the lens he's looking through, it's a reasonable position. There's a rather substantial difference between a casual refactor that changed a terminal to be consistent with all other terminals and a foundational logic shift required to make two terminals that are literally the same address in memory return different values -- but that's something I can know with deep knowledge of the code underlying these two issues. No way for Ernesto or any other customer to recognize that. One can be done just by removing what appeared to be a bug; the other would require significant and deliberate retooling of the code. Not to mention it would break regression tests (tests that don't exist for automatic error handling since at the time that feature came along, there wasn't a good way to automatically test for anything that triggered dialogs requiring human acknowledgement). There are levels of trust between tool vendor and tool user, and once those are breeched, the promises of the vendor aren't worth anything. That's the case here. So even explaining all of the foregoing logic doesn't really suffice to say that Ernesto is wrong in his defensive coding practices. That's something NI has to earn back for that user. So perhaps if the bug with the auto error handling gets fixed and nothing changes about the errors of the accessors for another couple versions, we can get to the point where Ernesto feels comfortable removing the unnecessary bits. But until then, he's right to continue his current practice, and I shouldn't have said otherwise. I apologize.

Never mind. You're right. Sorry.

Yes, there is a guarantee: both a statement from R&D and also just how much code we'd break if that ever changed. But if you want to continue connecting both, it's just your own programming time and run-time performance you're wasting, so go for it. I'll file the bug report. Definitely worked when the feature was first introduced (thanks to TomOrr0W for checking back to 2009). *head bang* This has not been a good LabVIEW day.

Paul: Been thinking about this more. I think I can see how this works, but I'd love to see your source code to play with it more. If at some point we're at a conference together, I'd love to look at it.

Paul: Your response is exactly why I thought inheritance is a bad choice here. "D:Exit()" on a state is not a well-defined method because it's behavior depends upon context. Having "D:Exit()" that ONLY does the exit work of D and not the exit work of B or A means that the transition can call "D:Exit()" and then could also call "B:Exit()" if and only if the transition knew itself to be crossing that boundary. Or, better -- it would just call B:Exit() and let B know to call D:Exit(). It's all design time knowledge -- using reflection means that design time information is being computed at run time, which is both inefficient and error prone. I know that neither of the alternatives I just now suggested fits cleanly into your existing architecture. Your need for reflection is clear to me given your current design. And while I would consider your architecture as a use case if I were working on reflection, I would still push back on the architecture itself. To inherit, you need Identity, State, and Behavior. All three. If you don't have all three, you shouldn't be inheriting. You don't have Identity. State D is not a flavor of state B. It is a substate of B. Any time you miss one of Identity, State, or Behavior but choose inheritance anyway, somethings work, but other things will become significantly more complicated. And a need for reflection is a bright red sign.

I'm familiar with the State Pattern. I've just never seen the inner states implemented through inheritance of the outer states. I've always seen that as composition. Once I pulled it apart, it made sense. Let me see if I understand: If the transition is from one inner state to another inner state, you call a method X. If the transition is from one inner state to another state outside the outer state, you call a method Y ("StopMotion" in the example). Either that method is responsible for calling an abstract core functions to be implemented by the inner states ("OnInterruptProcessTriggers" in the example) OR (not in the presentation directly but seems to be alluded to) the inner states would override "StopMotion" to add the behavior they need for that transition and use Call Parent to make sure they get the common transition code. Assuming I have that right, it all makes sense. What I'm not seeing is why any of the function invocations have to be decided at run time. It's all fixed function calls to match your state machine model. You never have to find the "common parent" for a given transition because every transition has its own method (that is only implemented starting at a particular level of your hierarchy). Where does the dynamic come into play?

What does the inheritance hierarchy look like? Are you saying that there is a class D that *inherits* from class B? I've never seen a state chart implementation where there would be an inheritance relationship between the outer and inner states. That's typically a "has a" not an "is a" relationship. I tried to picture what state (i.e. private data fields) B could have that should be inherited by D... I couldn't come up with any use cases. And the methods are all methods on class State ("Enter", "Exit", "Loopback", etc), not things inherited from B. Please explain how this works. I'm intrigued, as it sounds like a novel approach to state chart implementation.

I learned a lot about serialization from writing my library. Took me 2 years of research and planning. "All I want to do is flatten and unflatten some data and I need a library of 900 VIs to do it?!?!?!!" Yes, give or take a couple hundred. Turns out serialization is really a lot more complex than I ever would have thought when you really get down to the core. Bloating the string is one of the most fascinating issues, something I totally ignored when I created the original flatten-to-string behaviors for LV classes. To flatten an object, you obviously need to record the type. But what about an array of objects? Do you need the type for every element in the array? Yes, if the array is heterogenous; no if it is homogenous. Can that be factored out? Depends upon what you plan to do with the string! If you're always going to start at the front of the string and unflatten all the data then you can factor out lots of stuff because you have context for the remainder of the string. But if you're going to fly along the string and find subportions to pull out then you need every subportion to be a complete record. "I have an array of 10000 objects. I need only 1 of them." That's a real serialization requirement and it has severe impact on the format of the string itself! Formatting for localization, formatting for versioning, formatting for different encodings, formatting for transmission (requires more redundancy in the data), pretty-printing for human readability... it's a mess. The one main takeaway I had from my project? I support trade embargoes on any nation that tries to use a comma for a decimal point. I know... Britain and the USA are outliers here, but, seriously, it's called a "decimal point"... stop putting a tail on it! I can deal with two different systems for units. I can deal with myriad ways to format a timestamp (even different calendars). I'm supportive of arcane Unicode encodings so that every language ever can be recorded. But I hit my breaking point on commas as decimal points. Why would I want to live in a world where I can order a 1.125 meter steel beam then be charged for delivery of something over a kilometer long?!?! This table should not exist. Yes, my library provides support for such abominations, but it was while adding that feature that I became a strong proponent of cultural hegemony!

Oh, yeah. I forgot about that. There's a whole writeup somewhere discussing why I did things the way I did for that library. It's been a while since I worked on it. Sorry for the wild goose chase. Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data. I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included.