Jump to content

NI Week prognostications


Recommended Posts

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 beer_mug.gif . (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.

Link to comment

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

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.

Link to comment
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!!

Link to comment
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. ;-)

Link to comment

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.

Link to comment

Re:Byref objects

Your dreams are too limited. Think broader...

ohmy.gif 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. wink.gif

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. smile.gif (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.

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.