Is name mangling still needed when building code?

[Daklu]

This thread spawned as a result of AQ's request for users to explain why they use name mangling in this thread. I've taken the liberty to include a brief summary of the relevant discussion thus far:

------ Start Summary ------

QUOTE (Daklu)

Name mangling while building a project breaks any vis that depend on a path constant to a vi in the project. How do you work around this?

QUOTE (AQ)

Don't use name mangling. It's not needed.

QUOTE (Daklu)

Don't name mangle!?

The last time I skipped name mangling the economy collapsed, I lost my job, my wife left me, and worst of all my dog died! All sorts of scarey beasties will jump out of my closet if I don't name mangle. Surely you can't be serious!?

QUOTE (AQ)

Yes I am serious. And don't call me Shirley.

QUOTE (Daklu)

I don't trust Labview. What about the beastie that prevents me from having source code and distributed code with the identical library names loaded at the same time. Oi, the nightmares I'll have!

QUOTE (AQ)

That beastie is dead. Labview killed it by loading libraries with identical names in different application instances.

If you still think you need to name mangle, tell me what other beasties are frightening you. We think we've killed them all but it's possible there are still some that exist.

------ End Summary ------

The way Labview namespacing is tied to the library name seems like an odd decision since it creates potential implementation obstacles that apparently make name mangling the safer route to take, even if it isn't a completely satisfying solution. Maybe these aren't real issues at all and only exist in my mind...

First is the potential for name collisions in reuse code. I might have a Microwave class designed to capture debug output from the oven while the cafeteria has a Microwave class for automated cooking and the RF Lab has a Microwave class for testing wireless communications. My application needs to test the microwave oven while reusing code from the automated cooking process and pelting the oven with high intensity radiation. What is the preferred way to use all three classes in my project? Should I copy the code for each class and give them each unique names? Should I wrap each class in its own library and give the library a unique name? This seems like a hack since I'm not using the library to bundle related functionality (it's already bundled in the class) but only for the purpose of establishing a namespace. Using the library wrapper method, what namespace do the class' member vis have? LibraryName.ClassName.VIName? Or just LibraryName.VIName?

Second is the inability to create namespaces in a hierarchy that is logical for the organization. I want to be able to create a namespace that makes sense in my working environment. (<MegaBucksInc.ConsumerProductsDivision.HouseholdApplicances.MicrowaveOvens.Test.Microwave.lvclass>) The other microwave classes could be namespaced at <MegaBucks.Services.Cafeteria.Microwave.lvclass> and <MegaBucks.Communications.Wireless.Microwave.lvclass>. We had developers attempt to create a hierarchical namespace by nesting LVLibs but that proved to be unworkable.

Is there a reason namespaces aren't implemented as a library property that is independent of the file name, perhaps settable by right-clicking on the library in the project window?

QUOTE (Aristos Queue)

With exactly identical file names, you can have both your source and distribution in memory at the same time. You load your source in one project and your distrib in another project. They are thus in isolated application instances.

Couple questions rooted in my incomplete understanding of application instances:

• What happens when you load a library outside a project context, such as by opening a .lvlib file from the OS file system? Is there a default application instance that is used?
  
• After doing that, what happens if I then try to load another library with the same name outside a project context? Is another 'default' application instance spawned with a different name?
  
• How does Labview deal with this situation: An application is built with a static link to a "Honda" class to provide automobile functionality. Later on another "Honda" class is dynamically linked (since it cannot be statically linked) to provide lawnmower functionality. Does Labview automatically coerce the Honda lawnmower class into a different namespace so it can share the same application instance? Does Labview open it in a separate application instance and automatically provide communication between the two? Does the behavior change when moving from the dev environment to the run-time environment?
  

[Aristos Queue]

QUOTE (Daklu @ Feb 10 2009, 06:46 PM)

What happens when you load a library outside a project context, such as by opening a .lvlib file from the OS file system? Is there a default application instance that is used?

Yes, there is a default app instance. An app instance is simply a LV sandbox for VIs. All VIs always load into a given app instance.

QUOTE

After doing that, what happens if I then try to load another library with the same name outside a project context? Is another 'default' application instance spawned with a different name?

No. There is only one non-project app instance.

QUOTE

How does Labview deal with this situation: An application is built with a static link to a "Honda" class to provide automobile functionality. Later on another "Honda" class is dynamically linked (since it cannot be statically linked) to provide lawnmower functionality. Does Labview automatically coerce the Honda lawnmower class into a different namespace so it can share the same application instance? Does Labview open it in a separate application instance and automatically provide communication between the two? Does the behavior change when moving from the dev environment to the run-time environment?

Nope. You would simply get the Honda.lvclass that was already in memory in that app instance.

Your questions strongly hint that R&D has been significantly off track in our work on this problem, at least as far as your situtation is concerned -- it may apply to other users as well. Let me see if I can explain why your questions disturb me...

We [R&D] have been almost entirely concerned about *development* time collision of VIs/Libraries. The single biggest challenge that we have focused on "I have a bunch of VIs in my project. I create a source distribution of my VIs. Then I open my source distribution to make sure it was created correctly, and then my source distribution and my original source ends up cross-linked." This seemed to be the primary reason for all the prefixing/renaming that was taking place. Thus in that environment the project is aware of the links of everything that tries to join the project and it throws up a protective dialog if stuff that would create cross-linking tries to join the project. That dialog offers you the chance to open the new items in a separate project, where you could rename the items, put them in a library, or just realize that you didn't want that in the first project in the first place.

When you are done developing VIs, we expect you're going to go deploy them somewhere. This may be by building an EXE. This may be downloading them to a target. This may be by building a source distribution and running them in the development environment. But at that point, you are no longer editing the VIs. The presumption has been that when you are now running your VIs that you don't have these concerns about collision because your application is something that has been created. Even if you have a bunch of dynamically loaded VIs/classes, those dynamically loaded components are things that were designed in the context of the application; they know the framework that they are loading into, so there should be zero concerns about collision with the elements of the framework itself. When the components are independently developed by unrelated groups of developers, the dynamically loaded components should be placed in a library to namespace the elements... your Austin development team would have their pieces in a library named "Austin.lvlib", and your Shanghai team would have their pieces in "Shanghai.lvlib", so even if they both wrote a "DAQStuff.lvclass", those are two different qualified names when loaded into the framework.

Now, your questions seem to imply that you could have multiple unrelated applications -- the test lab microwave, the cafeteria microwave, etc -- all loading into the same run time environment. Under what conditions does that occur? Why does that even arise as a concern? When is there ever a single labview.exe that is running both of those applications?

The presumption is that all those different Microwave classes would never come together for the first time in the run time environment. Long before you ever got to that point, all these classes would have been loaded together in a project in development, and the project would have forced you to sort things out at that point, if the classes were not already in uniquely named libraries.

If you really are bringing these classes together for the first time in a run time scenario, it means that your use cases are far away from the common scenario envisioned by R&D.

QUOTE

The way Labview namespacing is tied to the library name seems like an odd decision since it creates potential implementation obstacles that apparently make name mangling the safer route to take, even if it isn't a completely satisfying solution. Maybe these aren't real issues at all and only exist in my mind...

Given that the library is the container for the member VIs/sublibraries, and given that the VIs/sublibraries know they are members of the owning library, choosing the library as the namespace seems very natural to me.

QUOTE

We had developers attempt to create a hierarchical namespace by nesting LVLibs but that proved to be unworkable.

What was their failure here? I'm going to guess that it was something like this:

You had two development teams, Alpha and Beta. And since the development efforts of these two teams might sometimes get used together, it was decided that Alpha should use "Alpha.lvlib" namespace and Beta should use "Beta.lvlib" namespace. So Alpha created two different toolkits, Ping and Pong. And when they went to namespace these toolkits, they were frustrated because they realized, darn it, we don't want to have to distribute Ping and Pong both together. But if both Ping.lvclass and Pong.lvclass are in the same owning library, then that implies that they want to distribute together -- libraries, by design, package stuff together.

Am I right?

National Instruments does not have a single "NI.lvlib" that namespaces everything that NI produces to keep it separate from user developed VIs/libraries. If you look around, you'll notice that a lot of NI libraries have "NI_" as a prefix, and within that library is all the stuff for a particular toolkit. The prefix is not something that we apply during the production of the source distribution... it is the name the library is initially created with.

Your suggestion of a "meta" namespace -- one where a library says, "I'm part of the NI namespace", and multiple libraries might claim that, is interesting. It severs the concept of the namespace from the concept of access scope. Currently, if something is inside the namespace then it has the right to access private VIs in that scope. But such a meta scope, which any library might join arbitrarily, obviously couldn't extend the right to access private functions to just any library that said, "Oh me too!" But as a way of providing a common namespace that everything produced by a given set of developers into a unique namespace, it might be useful. It doesn't invalidate the library as namespace -- as I said above, that is a very natural container, and the namespacing there is valuable. But a second form of namespacing -- one that is divorced from reciprocated ownership -- might be worth contemplating.

[Daklu]

QUOTE (Aristos Queue @ Feb 10 2009, 06:26 PM)

Your questions strongly hint that R&D has been significantly off track in our work on this problem, at least as far as your situtation is concerned -- it may apply to other users as well. Let me see if I can explain why your questions disturb me...

I honestly don't think 'significantly off track' is a fair assessment. You addressed, and fixed, a serious problem that affected a large number of people. (Me included!) Sounds like the resources were applied appropriately and effectively. Now that the big beastie is dead the little beasties can be discussed.

QUOTE

Now, your questions seem to imply that you could have multiple unrelated applications -- the test lab microwave, the cafeteria microwave, etc -- all loading into the same run time environment.

Actually I had not considered each of the three classes built into different applications running on the same computer. I assumed Labview would create separate application instances for each application and keep it all straight.

QUOTE

What was their failure here?

Very close. It was more along the lines of, "Let's use HouseholdApplicances as an umbrella namespace for all our tools. Within that we'll have several subnamespaces, such as Microwave, Blender, Toaster, etc. Within each of those subnamespaces we can implement individual libraries or create more subnamespace levels as needed." (Think .NET namespace hierarchy.) Using libraries of libraries (of libraries) to create hierarchical namespaces means that when any single 'leaf' library is loaded the entire hierarchy is loaded. Not the behavior they were hoping for.

QUOTE

...libraries, by design, package stuff together...

...your suggestion of a "meta" namespace -- one where a library says, "I'm part of the NI namespace", and multiple libraries might claim that, is interesting. It severs the concept of the namespace from the concept of access scope.

Exactly! Libraries and the way the work is a good thing. The bad thing is not being able to arbitrarily set a library's namespace independently of the library's file name. In my mind libraries and namespaces serve two completely different purposes. Libraries exist to package related code; namespaces exist to resolve name collisions. Namespaces should be, in my opinion, much more mutable than file names. (i.e. I should be able to change them without incurring the negative consequences of changing vi or library file names.)

QUOTE

Currently, if something is inside the

namespace

then it has the right to access private VIs in that scope.

That may be correct from an internal architectural viewpoint, but from my end-user perspective it's false. It should say 'if something is inside the library it has the right to access private VIs in the scope.' From the end-user perspective Labview doesn't even implement namespaces. It implements libraries. Namespace and library are not interchangable terms.

QUOTE

But such a meta scope, which any library might join arbitrarily, obviously couldn't extend the right to access private functions to just any library that said, "Oh me too!"

As you mentioned above, namespace scope is completely separate from access scope. I view namespaces as a kind of virtual organizational hierarchy that is independent of the implementation architecture. Maybe I have an Animal base class from which I derive Pteridactyl.lvclass, Golden Retriever.lvclass, and Cutthroat Trout.lvclass. In my namespace I should be able to put Pteridactyl in <Extinct.Prehistoric.Cretaceous>, Golden Retriever in <Household.Occupents.Pets>, and Cutthroat Trout in <Dinner.BBQ.Yummy> if that's what makes sense in my environment.

QUOTE

But as a way of providing a common namespace that everything produced by a given set of developers into a unique namespace, it might be useful. It doesn't invalidate the library as namespace -- as I said above, that is a very natural container, and the namespacing there is valuable.

To clarify, I have no objection to using the library filename as part of the namespace, such as using it as the last element in the namespace tree. (<Extinct.Prehistoric.Cretaceous.Pteridactyl>) I think that makes perfect sense. I object to the requirement to wrap libraries in other libraries to build a fully qualified namespace.

QUOTE

When the components are independently developed by unrelated groups of developers, the dynamically loaded components should be placed in a library to namespace the elements... your Austin development team would have their pieces in a library named "Austin.lvlib", and your Shanghai team would have their pieces in "Shanghai.lvlib", so even if they both wrote a "DAQStuff.lvclass", those are two different qualified names when loaded into the framework.

This completely contrived scenario, I hope, illustrates the problem of tying the fully qualified namespace to the source code architecture. Granted these scenarios are not among the most common issue encountered by Labview developers, but I can't believe the problems they illustrate are so rare as to be negligible.

Suppose I'm using two reuse libraries developed by the Austin development team: Ping and Pong. On my next project I decide to use Pong again, but I also need a few other reuse libraries they developed, Ding and Dong. For parallel project I want to use Ping, Ding, and add a couple classes they created: Sing and Song. Since we want to be sure we don't encounter name collisions between their code and our code now and in the future, we decide to namespace their code. (They don't want to change the name of their reuse code because it will break their applications that use it.) I see a few options, none of which I particularly like:

-- I can lump all their reuse code in a single library, Austin.lvlib. Lots of unnecessary code gets distributed with each application.

-- I can create copies of the source distribution for each reuse library a given project uses, and include only those copies in a library specifically built for that application. (i.e. Project1_Austin.lvlib) This defeats the whole point of code reuse.

-- Rename each of their libraries to a (hopefully) unique name, such as Austin_Ping.lvlib, Austin_Pong.lvlib, etc. Preprocessing their code, I think, is a bad idea. If we ever use reuse code (Sing.lvclass) they created with a non-renamed library as a dependency (Ping.lvlib) we'll end up with duplicate code in Austin_Ping.lvlib and Ping.lvlib unless we manually edit Sing.lvclass to redirect the links to Austin_Ping.lvlib. This problem could easily compound over time until eventually we have two complete copies of their source distribution loose in the company--one using their native names and one with the Austin_ prefix.

(There were a few more comments I wanted to make, but I'm literally falling asleep at the keyboard. I hope this is reasonably coherent.)

[Aristos Queue]

QUOTE (Daklu @ Feb 11 2009, 02:04 AM)

(There were a few more comments I wanted to make, but I'm literally falling asleep at the keyboard. I hope this is reasonably coherent.)

It is coherent. :-)

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.

[Daklu]

The Ping/Pong scenario is contrived, but the issue it illustrates is real enough to me. This is the real situation I'm in right now.

I work at MegaBucks, a large company spread across several organizational divisions and dispersed geographically. In my group I was the first one to start using Labview. I created several reuse libraries to solve immediate problems and facilitate future code. Over time a few other people in my group started using Labview and used my reuse libraries. A little more time passed and I discovered a group of Labview users in a different division working on similar problems. I have since found a few other islands of Labview in various locations.

When I first created those reuse libraries I gave them names that were descriptive enough for the context in which I anticipated using them. Robot.lvclass, ButtonPusher.lvclass, DataAnalysis.lvlib, etc. Unfortunately these names are too general to be meaningful when the code is shared with the other Labview users. In the best case the purpose of my reuse code is somewhat obscured in their project; worst case is a name collision with one of their reuse libraries, which incurs the developer overhead I mentioned above. Either way sharing reusable code is hindered.

Maybe I should have given my libraries more descriptive and unique names. After all, Robot.lvclass is an extremely general name and a good developer should anticipate a name collision somewhere down the road.

I suppose the name could have described what the robot does rather than what it is. Except I work in a development test environment; equipment is frequently repurposed to accomplish new tasks. My control panel testing robot today can easily become a glue dispensing robot tomorrow.

I could use NI's convention of prefixing the library with an abbreviation and call it MB_Robot.lvclass. Oops, the other groups might use that convention too, so I'll have to extend that convention to include the organizational structure: MB_ConsumerProducts_HouseholdApplicances_MicrowaveOvens_Test_Robot.lvclass. At least that accurately describes what device the code is intended for. Umm, no thanks. Not only is the name unwieldy, but when the Consumer Products division is dissolved in our biannual company reorganization the name is no longer meaningful.

Maybe I should give the robot an internal code name and use that as the library name, Robot_Homer.lvclass. The problem is that in my group the robot has been known simply as "the robot." I might call it Homer but the name doesn't have any meaning outside the context of my brain. People get irritated because they view it as unnecessarily complicating discussions. (I've tried it.)

As it turns out, I did essentially ensure a unique name by using OGB name mangling to append an acronymn of my group's informal name. Of course, the acronym is meaningless to everyone except me and it is now firmly embedded in legacy code.

-----------------

In it's simplist form the namespace could simply be string property attached to a library. When Labview attempts to load a library with the same name as a library already in memory, it compares the namespace of the library in memory with the namespace of the library on disk. If they are the same then the libraries are the same; different namespaces = different libraries. The namespace itself doesn't have to be used anywhere except when loading identically named libraries.

(One of my favorite sayings is, "If the solution seems simple I don't know enough about the problem." Obviously there are many design considerations in play I know nothing about. I don't mean to suggest the solution is this simple; I'm using this as an example to further illustrate my concept of namespaces in Labview.)

[Aristos Queue]

QUOTE (Daklu @ Feb 11 2009, 12:27 PM)

The namespace itself doesn't have to be used anywhere except when loading identically named libraries.

If the namespace is not used anywhere other than load, how do you invoke subVI calls? Suppose you have two copies of X.lvlib, each of which contain Y.vi. When you load the second X.lvlib, according to your scenario, we would put that library in a new namespace Temp:X.lvlib. Now you load Alpha.vi, which calls X.lvlib:Y.vi. It is going to call the original X.lvlib:Y.vi, regardless of which one it was expecting to invoke because that's the one that got the name.

The goal of namespaces is *not* merely so that you can have two things of the same name in memory simultaneously. It is actualy so that you can *use* those two items simultaneously, and meaningfully keep straight which one is being used by any given caller. Being able to load a VI isn't much good if you can never invoke it.

[shoneill]

QUOTE (Aristos Queue @ Feb 11 2009, 11:40 PM)

If the namespace is not used anywhere other than load, how do you invoke subVI calls? Suppose you have two copies of X.lvlib, each of which contain Y.vi. When you load the second X.lvlib, according to your scenario, we would put that library in a new namespace Temp:X.lvlib. Now you load Alpha.vi, which calls X.lvlib:Y.vi. It is going to call the original X.lvlib:Y.vi, regardless of which one it was expecting to invoke because that's the one that got the name.

The goal of namespaces is *not* merely so that you can have two things of the same name in memory simultaneously. It is actualy so that you can *use* those two items simultaneously, and meaningfully keep straight which one is being used by any given caller. Being able to load a VI isn't much good if you can never invoke it.

I can also see need for something like this. The ability to create extensible frameworks with Objects (Loadable at run-time) which may have its origins well beyond our control means we cannot be sure that name collisions don't take place. I don't know the internals to LabVIEW but surely there must be a way to do this. But as I tell my customers quite often, everything's possible, it's just a question of manpower.....

While I personally haven't (yet) run into this problem, I see it being an issue in the near future (for some apparently it's an issue already).

Shane.

[Aristos Queue]

QUOTE (shoneill @ Feb 11 2009, 05:03 PM)

I can also see need for something like this. The ability to create extensible frameworks with Objects (Loadable at run-time) which may have its origins well beyond our control means we cannot be sure that name collisions don't take place. I don't know the internals to LabVIEW but surely there must be a way to do this. But as I tell my customers quite often, everything's possible, it's just a question of manpower.....

Actually, no. Some things are logically impossible: A general hash function that never produces collisions. Sorting data faster than O(n*log n). Preventing name collisions among a system where anyone can contribute a name without a central database of names.

There are ways to mitigate name collisions, but not prevent them. Hearing the use cases is important because they affect which mitigation schemes might work best. So keep talking... I'm listening.

[shoneill]

QUOTE (Aristos Queue @ Feb 12 2009, 04:48 AM)

Actually, no. Some things are logically impossible: A general hash function that never produces collisions. Sorting data faster than O(n*log n). Preventing name collisions among a system where anyone can contribute a name without a central database of names.

There are ways to mitigate name collisions, but not prevent them. Hearing the use cases is important because they affect which mitigation schemes might work best. So keep talking... I'm listening.

Well, yeah there are some things which are logically impossible, so manpower doesn't make any difference there. I think you are choosing to ignore the context of my comment but it's OK because you're right, not EVERYTHING is possible by throwing manpower at it. :worship:

I think a limitation of the current system (Not meant in a judgemental way) is that the name is given the status of unique identifer, no? Why should it not be possible, for example, to have each and every LVClass (Or Object of a class more likely) have member data which is set by the current run-time as a unique ID upon loading. Could this not be used to differentiate between Classes of the same name? Perhaps there are really good reasons why an identifier must be static but I've unfortunately only enough knowledge to post questions on the subject, not answer them.

This would extend to more than just LVClass I suppose, it's more a generalisation. Is this possible with LV today, probably no. Is it impossible to do, probably no. So while it might be impossible to prevent two classes having the same name, just as it is impossible to stop two classes containing a U32 called "Index" and set to zero, there are always possibilities to prevent this leading to the problems mentioned prevoiusly in the thread.

I'm not trying to be a smart-###### ( ) but I don't see why something like this should be labelled impossible. Difficult, sure. Unlikely to ever be implemented, perhaps. Impossible? I don't like the word....

Shane.

PS On mature recollection I reckon inheritance could be very difficult if a child class is dynamically loaded where more than one possible parent is in memory.....

[Aristos Queue]

QUOTE (shoneill @ Feb 12 2009, 02:22 AM)

PS On mature recollection I reckon inheritance could be very difficult if a child class is dynamically loaded where more than one possible parent is in memory.....

Yep... that's where I was going next... dynamically load the parent, give it a run-time only ID, now dynamically load the child... and the grandchild... it gets messy quick. Now, there are TONS of applications where you don't need multiple levels of inheritance to be dynamically loaded, so your suggestion has significant merit. But it is still one mitigation, not a general solution.

[Daklu]

QUOTE (Aristos Queue @ Feb 11 2009, 02:40 PM)

If the namespace is not used anywhere other than load, how do you invoke subVI calls?

Magic?

QUOTE

Suppose you have two copies of X.lvlib, each of which contain Y.vi. When you load the second X.lvlib, according to your scenario, we would put that library in a new namespace Temp:X.lvlib. Now you load Alpha.vi, which calls X.lvlib:Y.vi. It is going to call the original X.lvlib:Y.vi, regardless of which one it was expecting to invoke because that's the one that got the name.

Yep, bad oversight on my part. I hadn't thought about how to link the block diagram subvi with the runtime instance of the subvi. That's probably why I'm a test engineer instead of a design engineer--breaking things is easier (and far more entertaining) than building them.

My original thought had been for developers to apply namespaces on an 'as needed' basis on their dev computer. That would maximize malleability and avoid the overhead (both in terms of processing time and human management) associated with designing and maintaining a complete namespace structure. In retrospect it's obvious that doesn't work. The deployed application might try to reference a pre-installed shared library that, even though it is the same library, has a old namespace. The app, finding mismatched namespaces, determines the library it needs isn't present and throws an error.

Following that line of thought leads me to believe a fixed, centralized namespace lookup table is required. (Although if the table is generated at runtime it would provide more flexibility.) The question that naturally comes to mind next is: What's the point of implementing namespaces if you can't change them without breaking applications? Have the problems of changing filenames simply been shifted to the realm of namespaces?

I actually thought about this a lot today and think namespaces are still advantageous. Naturally a library has a 1-to-1 relationship with its filename. Is there any reason a library couldn't have a 1-to-many relationship with namespaces? I believe allowing a library to be accessed in source code through multiple namespaces could help provide a migration path for Ping/Pong situations.

For convenience, let's assume the default namespace for libraries is <User>. When we realize Austin's <User.Ping> conflicts with our <User.Ping>, we call them up and decide they will use the <Austin> namespace and we will use the <Seattle> namespace. We each add the namespace to our Ping.lvlib source code and redistribute the built code to our developers. Now their library can be accessed via the <User.Ping> and the <Austin.Ping> namespaces. Similarly our library can be accessed via the <User.Ping> and the <Seattle.Ping> namespace.

In the application we are building that uses both libraries we reference them through their new namespaces, <Seattle.Ping> and <Austin.Ping>. Legacy applications which use only our library continue to reference it through <User.Ping>. Using this scheme we can continue to make updates to our Ping library and all legacy applications will remain functional. Our legacy applications can be updated to reference <Seattle.Ping> instead of <User.Ping> at our convenience.

There is a significant limitation that this technique doesn't fix. An application cannot reference either library via <User.Ping> if both libraries are present on the system, unless one of them drops out of the <User> namespace. That puts some restrictions on having multiple applications using those libraries installed on a single computer.

Still a net positive in my mind, even if not as easy to use as I originally imagined.

QUOTE

Actually, no. Some things are logically impossible: A general hash function that never produces collisions.

An identity hash would do it. It has limited practical value (to say the least) but it is logically possible.

QUOTE

Sorting data faster than O(n*log n).

Given prior information about the distribution of the data to be sorted algorithms can sometimes be constructed that operate faster than that. It also depends on the type of sorting being done. I can sort my dirty laundry in O(n). (Whites, darks, and colors.) Oddly, when I'm tired my laundry sorting algorithm improves to O(1). Special cases? Yep, but logically possible.

QUOTE

Preventing name collisions among a system where anyone can contribute a name without a central database of names.

Yeah, okay... you got me there.