> If it is not possible to put a library in a class, how
> could any member of a library directly access the class data?
A class is a kind of library. The member VIs of the class can access the class data. No one else can. Member VIs can be public or private (or two other scopes). The private ones are only usable inside the class. The public ones are usable by anyone. If you want everyone to have access to some bit of data, write a member VI that provides that access.
I am not sure why I didn't kudo this idea when I first read it, but I really should have. Unfortunately that would not have been enough to save it from an auto-decline.
>> If it is not possible to put a library in a class, how
>> could any member of a library directly access the class data?
>
> A class is a kind of library. The member VIs of the class can access the class data. No one else can. Member VIs can be
> public or private (or two other scopes). The private ones are only usable inside the class. The public ones are usable by
> anyone. If you want everyone to have access to some bit of data, write a member VI that provides that access.
Sorry, please let me clarify.
It is possible to put a library inside another library.
Therefore, I think it should be possible to put a library in a class. The library could then access the class data because it is part of the class just like any other VI in the class.
> It is possible to put a library inside another library.
> Therefore, I think it should be possible to put a library in a class.
Ah. I misunderstood your previous question.
Yes, if a library could go in a class, then it could access the class data. We have deliberately blocked that functionality.
So, now that I understand your question, I can give a better answer:
> If it is not possible to put a library in a class, how could
> any member of a library directly access the class data?
There is no such mechanism: VIs outside the class cannot directly access the private data. This is a deliberate language design decision. Create accessor methods in your class for others to use. The other library can use any public method. If you want, you can put those methods into Community scope and then have the class name the other library as a friend. Friends can access Community scope methods.
Any accessor method that is static dispatch, marked as "inline", and does not have error terminals is performance-wise no different than direct access. The first two characteristics are the defaults for new accessor VIs... the third is easily toggled in the New Accessor dialog.
I answered this in my first post in this thread years ago. That answer is still true: we simply didn't see many good use cases for it, and the few good ones were rare enough that we decided to cut the feature. You notice that this idea only got 6 kudos in 6 years? There's minimal demand for it. Adding support for it would dramatically complicate namespace computations. It is a weak use case for customers and a complexity risk for stability. Those two together mean we aren't going to do it.
Any idea that has received less than 6 kudos within 6 years after posting will be automatically declined.