Group project items by namespace

[Daklu]

Since my request for separating namespace from library membership hasn't gone anywhere, I'll throw out a less disruptive idea:  provide an option to group project items by namespace.

Often I have groups of vis or classes that are related to each other, but do not depend on each other.  (For example, the LapDog message classes are logically related to each other, but not functionally related to each other.)  Since grouping by namespace helps me understand the code, I typically put them all in the same library, even though they are not functionally linked.

The alternative is to name each message class according to its complete namespace (i.e. LapDog.Messaging.NativeMessages.StringMessage.lvclass) and skip the lvlib.  Doing this means I lose the grouping feature in the dependencies tree.  If there were an option to automatically group project items in a tree according to their namespace, I would get the benefit of grouping without incurring the overhead of library membership.

Currently LV includes the file extension as part of the namespace.  I think that's fine identifying a specific vi.  When grouping within the project window I don't think the extensions should be used.  For example, a class method that is a member of a lvlib might have a fully qualified namespace of,

MyLib.lvlib:MyClass.lvclass:MyVi.vi

That vi should appear in the tree at the same place as a single vi with the filename,

MyLib.MyClass.MyOtherVi.vi.

(I really think Namespace should be a new tab in the project window like the Items and Files tabs, since it represents a different view of the project.  However, that would probably be more work to implement so I'll pare down the request.)

[JÞB]

On <Project> Through <Application instance>.  You missed the difference.  The Fully Qualified Name is available. and depends on what proxy opens the object as well as what the object and proxy know.  Would you make every VILIB member private?  Where do friendships end?  What about all those green arrows we have learned to deal with? (Sync with other application instances) What about Teststand modules called through projects (relative to the base path in the lvproj file) and by either absolute or relative (to the sequence) paths.

No, not yet... but there are potentials......................................

Until then.  Stop overcoupling your code.  A folder, repository or trunk will group logically related (but in-cohesive) modules without interjecting a namespace.

Or did I miss the point? (Its possible- I'm not a CS guy)

[AristosQueue (NI)]

They are already grouped by namespace. You don't have an option to put them *not* by namespace. Libraries keep all of their contents together in the tree.

[Daklu]

You don't have an option to put them *not* by namespace.

This is only true in Labview's world where library membership is the only way to give an item a namespace.  From my perspective, I don't have an option to *not* group them by library.  Libraries and namespaces serve different purposes:  Libraries are functional groupings of related code the should be deployed together because of mutual dependencies.  Namespaces are logical grouping of code that help organize and give context to the items within them.

To copy an example from my other idea...

Libraries auto-load because there is the tacit assumption that everything in the library is necessary for the code to work.  If something is missing then the code won't compile.

With namespaces that assumption doesn't hold.  Just because Foo.lvclass and Bar.lvclass are both members of the NI.Frameworks.Widget.FunnyName namespace doesn't mean both must be loaded for either to work correctly.  Heck, they can be completely independent from each other just like two classes in adjacent directories can be independent.  They just happen to share the same namespace.

With the current system if I want Foo and Bar to share the same namespace I must make them members of the same NI.Frameworks.Widget.FunnyName library.  If I later want to add Baz.lvclass to the namespace, I have to add it to the library and redeploy the entire library to the users, even though nothing has changed in Foo or Bar.  There's no reason I shouldn't be able to deploy only Baz and have it automatically join the NI.Frameworks.Widget.FunnyName namespace (not library.)

In my previous idea I suggested separating library membership and namespaces.  I still prefer that solution, but this idea gives another option for how the project items are displayed in the project window.  It doesn't change anything about how libraries or library membership works.  All it needs is a parsing algorithm to analyze the namespaces of the VIs in memory and some way to display it to the users in the project window.  I whipped up a simple vi to illustrate the idea.

On the left are the fully qualified namespaces of the items in memory.  On the right is how they would be displayed in "Namespace View."  Note the first two vis are class members contained in the NI.Frameworks library.  The third vi isn't a member of any library, and the fourth vi is a member of a different class but not a member of the NI.Frameworks library.  However, they are all grouped under the FunnyName namespace to illustrate the relationship.

Or did I miss the point?

Either you missed my point or I missed yours.  I have no idea what you're talking about. 

My primary use case for this feature is with deploying reusable code.  In the image above the NI.Frameworks library could represent some core functionality of a package.  BarHelper.vi could be an optional add-on that does something with the Bar class that is useful in specific situations.  It "belongs" with Bar in the logical sense--you'll only use it if you're already using Bar for something else.  It does not belong with Bar in the deployment sense, because it is optional and isn't universally required by everyone who will use Bar.

[JÞB]

Yes, we missed each others points.

NI R&D could either A) spend a lot of effort to build a library package deployment feature or B) invest in integrating VIPM with LabVIEW.  They already did B.

[Daklu]

NI R&D could either A) spend a lot of effort to build a library package deployment feature or B) invest in integrating VIPM with LabVIEW.  They already did B.

This still isn't relevant to the idea I'm proposing.  I didn't explain my use case very well, but the idea doesn't have anything to do with the actual process of deploying code.  It's entirely related to how the project code is displayed in the project window, and VIPM doesn't influence that in any way.

When I am planning reusable code, one of my concerns is "how can I communicate to the user how part x relates to part y?"  In the example above BarHelper.vi is related to the Bar class, even though it is not a member of the Bar class or the Frameworks library.  I want it to be grouped with the Bar class because it creates an association between Bar and BarHelper in the user's mind and makes it easy to find.  I'm prevented from established that grouping because in order to achieve that grouping I must make BarHelper a member of the Bar class, which I don't want to do.

Namespace view is a way to present that grouping to the users without changing any of the existing mechanics of the actual namespaces in Labview.

[AristosQueue (NI)]

JeffP

You used the term "namespaces". LabVIEW does have namespaces. You don't like the fact that they are tied to libraries. That does not change the fact that when you ask for organization by namespaces, you've already got it.

That dot notation you're using? There's nothing formal about that. Plenty of people use periods in the names of files all the time without those having anything to do with file organization.

What you are asking for, as it is phrased currently, is a way to reorg the project tree using your personal naming conventions. Not an idea that is likely to gain much traction.

If you would like a different way to define namespaces, that's a totally different request and is one that is already on the exchange.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-namespacing-and-library-membership-independent/id...

[Daklu]

Uhh... AQ?  I don't know who JeffP is or why you are addressing your response to him, but I assure you he is not the author of this idea.  Here's a screenshot of what *I* see in my browser.

---

---

You don't like the fact that [namespaces] are tied to libraries.

You're right, I don't like it.  I think it is unnecessarily restrictive and it prevents me from organizing code logically.

That dot notation you're using? There's nothing formal about that.

I know.  The namespace delimiter could be anything.  Dot notation has the advantage of being fairly common.

What you are asking for, as it is phrased currently, is a way to reorg the project tree using your personal naming conventions.

What I'm asking for is an alternate way to view the items in the project because it is useful to be able to do that.  I prefer dot notation and I think it makes sense to use it, but I don't much care what namespace delimiter is ultimately used.  Pick one and go with it.  The important part of the idea is to give us some way to group code hierarchically without relying on library membership.

Not an idea that is likely to gain much traction.

Yep, I know.  Par for the course.

If you would like a different way to define namespaces, that's a totally different request and is one that is already on the exchange.

Thank you, I am aware of that idea--I wrote it.  As I said in the original post, the purpose of this idea is to present an alternative solution that gives me most of the benefit of separating namespace from library membership while (presumably) requiring far less work from R&D to implement.

[AristosQueue (NI)]

Sorry, Daklu... Replies were written by " Jeff·Þ·Bohrer" and I got confused about who was the original author. My arguments against this idea stand. I still like the other one.

[Daklu]

I still like the other one.

I prefer the other one too.  This idea is a band-aid.  Given it has received 0 votes, I don't expect anything to come from it.

[tst]

> ...I know.  The namespace delimiter could be anything.

Maybe we can use Þ...