NI Week prognostications

[Daklu]

Since I'm eagerly awaiting to hear how Labview 2009 (I'll go way out on a limb and assume NI will announce a new release) will extend OOP and I've had no luck prying the information out of crelf or AQ, I thought I'd throw out my guess for public review ridicule. Feel free to chime in with your own guesses--if you guess right I'll reward you with a . (The icon, not the real thing...) I'm also interested in hearing what missing oo feature users think would have the most impact on programming oo applications in Labview.

My impact list:

1. ByRef Objects - Yes, you can implement byref behavior using single element queues, but having native support for byref objects would eliminate the (sometimes complex) workarounds needed to get that behavior. Byref objects would be huge! At the same time, I've read that NI has no desire to pursue that as it violates the principle of data-flow and encroaches on the solution Endevo provides.

2. Interfaces - So much of good oop design relies on interfaces I would think (and hope) that NI is figuring out how to do this. This is actually the #1 item on my wish list. I can live without native byref objects. Working around the lack of interfaces is harder.

3. Constructor/Destructors - Another carryover from other languages that could change the fundamental way objects are developed and used, I doubt this is on the roadmap for inclusion. The Decision Behind the Design document clearly outlines why they don't fit the Labview paradigm. (It sure would be nice if LV called destructor methods when the Abort button was clicked.)

That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is...

User defined namespaces -- or at least improved namespacing.

[Michael Aivaliotis]

User defined namespaces -- or at least improved namespacing.

What do you mean by this?

PS: Maybe next time you should apply for the Beta program.

[Daklu]

PS: Maybe next time you should apply for the Beta program.

I've done NI betas in the past but I really don't have time to be a good beta tester without using the beta version for everyday dev work, which for business reasons doesn't really work out very well. Besides, if I already knew what was coming up I wouldn't be having so much fun trying to figure it out.

You make a good point though... I suspect most of the common posters are on the beta and can't post their guesses.

What do you mean by this?

In Labview namespacing is determined by the name of the library. For example, the Read method in my Voltmeter class has a fully qualified name of Voltmeter.lvclass:Read.vi. Associating namespace with the filename has all sorts of drawbacks: Reusable code modules must have a filename that is guaranteed to never conflict with another code module name, now and in the future. Nesting libraries to create hierarchical namespaces is impractical in Labview. Loading a single vi in one library will load the entire library tree... not something that leads to efficient programming.

There was some discussion about it back in Feb where I explained the problems in more detail to AQ. AQ did say in that thread, "And I think it will provide fodder for contemplation for the next few years. I say that because I don't want you to think the feedback is lost even though nothing may come of it for many years. This would not be the sort of feature that would be rushed into a release."

Looks like my guess was a swing and a miss.

[Abdullah R]

My impact list:

1. ByRef Objects - Yes, you can implement byref behavior using single element queues, but having native support for byref objects would eliminate the (sometimes complex) workarounds needed to get that behavior. Byref objects would be huge! At the same time, I've read that NI has no desire to pursue that as it violates the principle of data-flow and encroaches on the solution Endevo provides.

2. Interfaces - So much of good oop design relies on interfaces I would think (and hope) that NI is figuring out how to do this. This is actually the #1 item on my wish list. I can live without native byref objects. Working around the lack of interfaces is harder.

3. Constructor/Destructors - Another carryover from other languages that could change the fundamental way objects are developed and used, I doubt this is on the roadmap for inclusion. The Decision Behind the Design document clearly outlines why they don't fit the Labview paradigm. (It sure would be nice if LV called destructor methods when the Abort button was clicked.)

That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is...

User defined namespaces -- or at least improved namespacing.

I think #1 and #2 would be nice to have. If they introduced namespacing, that would be ok but not like WOW!!

[Aristos Queue]

1. ByRef Objects

Your dreams are too limited. Think broader...

2. Interfaces

Your dreams are too broad. Insufficient time has elapsed for such a grandiose feature to come into being.

3. Constructor/Destructors

Would you settle for one out of two?

That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is...

User defined namespaces -- or at least improved namespacing.

Some of you may be thinking, "But I thought .lvlib files are namespaces." Yeah, that's what I thought too. But after conversations with Daklu, I know that what he's asking for is the ability to have namespaces that can span multiple library files, something, perhaps, like X1.lvlib and X2.lvlib, etc, that, when loaded in memory, are all the X.lvlib namespace. Or something like that. This is in no way shape or form a hint of things to come -- off the top of my head I can think of several problems with that particular implementation -- but it's what Daklu is hoping for. His use cases are as a way of having a single module developed in several separate parts, without having a central file be the bottleneck for development, or so that a company could have a top-level namespace for all of its separate products.

Curiously enough, of the top three big improvements to OO, none of them make your list. But I think you'll like your presents none the less. ;-)

[Christian_L]

If you're around on Monday for Alliance Day you may want to stop by the following session at 4:30pm to see some new OO features in action.

Session ID:AD2650

Title:Tools and Techniques for Total System Configuration

Abstract:Examine a reference design of a generic configuration editor framework that can be customized to handle a variety of configuration requirements in different applications and industries. Configuration items are defined using LabVIEW classes, class inheritance is used to quickly extend functionality throughout the configuration tree, and XML stores the configuration data for use in a deployed application.

[Aristos Queue]

Session ID:AD2650

Title:Tools and Techniques for Total System Configuration

You know what makes this NI Week so exciting? OO being used in so many places, I'm not even aware of all the presentations, demos, etc, that are using it!

[Ernest Galbrun]

The functionality I would enjoy in LVOOP are multiple inheritance, and the possibility to have protected data members.

[vugie]

Your dreams are too broad.

Same, as I guess, applies to templates? Functions overloading?

[Ernest Galbrun]

... And polymorphism

[David Wisti]

I can only hope that LVOOP will extend to Real-Time targets in 2009.

[Daklu]

Re:Byref objects

Your dreams are too limited. Think broader...

I'm shocked NI is pursuing any aspect of this, and then to learn my dreams are too limited...

Re:Interfaces

Your dreams are too broad. Insufficient time has elapsed for such a grandiose feature to come into being.

I didn't expect it to be released this year, but I still hold out hope that it is something you are actively developing. (And your post hints that you are.)

Re:Constructors/Destructors

Would you settle for one out of two?

In truth I'll settle for whatever I can get. Like the byref objects I'm surprised and excited we're getting anything here.

Some of you may be thinking, "But I thought .lvlib files are namespaces." Yeah, that's what I thought too. But after conversations with Daklu, I know that what he's asking for is the ability to have namespaces that can span multiple library files, something, perhaps, like X1.lvlib and X2.lvlib, etc, that, when loaded in memory, are all the X.lvlib namespace. Or something like that.

The main changes I would like to see in namespacing are:

1. Decoupling the namespace from the filename and allowing the library author to define its namespace. (No more name mangling!)
2. Allowing a library to be exposed through multiple namespaces. This provides a migration path for resolving namespace conflicts in legacy code.
3. Having the ability to nest namespaces. This helps prevent namespace conflicts in the future.

Multiple libraries sharing the same namespace isn't necessary for my use case and off the top of my head I think it introduces more problems than it solves.

...but it's what Daklu is hoping for.

I hope for lots of things... disappointment and I are well acquainted.

His use cases are as a way of having a single module developed in several separate parts, without having a central file be the bottleneck for development...

Not so much that as a way to organize and avoid namespace conflicts with all the different reusable code modules that we have now and will develop in the future.

...or so that a company could have a top-level namespace for all of its separate products.

That too. Think .NET namespaces.

Curiously enough, of the top three big improvements to OO, none of them make your list. But I think you'll like your presents none the less. ;-)

I can hardly wait for Christmas morning.

If you're around on Monday for Alliance Day you may want to stop by the following session at 4:30pm to see some new OO features in action.

Not I, but hopefully one of the Lava tweet providers will. (And maybe the presentation will be available for download afterwards?)

The functionality I would enjoy in LVOOP are multiple inheritance, and the possibility to have protected data members.

Interfaces address the same problems multiple inheritance does, but does so in a cleaner way IMO.

I can only hope that LVOOP will extend to Real-Time targets in 2009.

Based on a previous post by AQ, I'm 99% sure you won't be disappointed.

[crelf]

Re:Byref objects... I'm surprised and excited we're getting anything here.

You'll love it - but with power comes responsibility: remember to only use it when appropriate (am I starting to sound like a broken record yet?)

[Michael Aivaliotis]

No need to wait anymore. Just watch the video and download the installer.

[Aristos Queue]

No need to wait anymore. Just watch the video and download the installer.

As far as OO is concerned, the video says "there are lots of OO enhancements in LV 2009, including targeting to real-time hardware." The list is WAY longer than that. I'll write something up for next week (when the release is official).

[Michael Aivaliotis]

As far as OO is concerned, the video says "there are lots of OO enhancements in LV 2009, including targeting to real-time hardware." The list is WAY longer than that. I'll write something up for next week (when the release is official).

Or you can download it, install it, and read the help docs that describe the new features.

[Christian_L]

Not I, but hopefully one of the Lava tweet providers will. (And maybe the presentation will be available for download afterwards?)

The reference design that will be presented is already available on ni.com. Search for 'xCE'. Of course you'll need LV 2009 to load the code.