"Really" get the class name at run-time

[mike5]

Hi all,

I've searched the Internet and this site, and still didn't find what I was looking for - I guess I'm still a n00b

I would really like to get the name of the LV class and do this for all its ancestors.

So it will by a dynamic dispatch method that should return all the class names back to the base class.

Can someone please help me do this?

I've found these two threads:

but they are a bit over my head, to get anything out of them.

Thanks in advance, Mike

[Francois Normandin]

I would really like to get the name of the LV class and do this for all its ancestors.

So it will by a dynamic dispatch method that should return all the class names back to the base class.

HI Mike,

take a look at this API. And find attached the latest version* I use.

There is code for getting the class hierarchy (array of refs or array of paths).

*Disclaimer:

This version 2 of the API is not in the Code Repository yet because I haven't ported it back to 8.6 and haven't retested all methods, so use at own risks. But between you and me, the code for hierarchy is safe.

I also changed the package naming convention since version 1, so you might get a palette conflict if you have both installed at the same time. It might go back to what it was, but most likely, I'll just change the place where the code is stored and where it's installed in the palette to be able to install both. Version 1 becoming "deprecated" simply because I'd rather call it lavag_lvclass_api than normandinf_lvclass_api...

lava_lib_lvclass_api-2.0.0.15.vip

[mike5]

Thanks, I'll take a look, but what do I do with a VIP file?

Br, Mike

Edited August 12, 2010 by mike5

[Francois Normandin]

Thanks, I'll take a look, but what do I do with a VIP file?

Br, Mike

Download VIPM from jki.net. It's a code reuse package manager. Very useful to distribute code, get code from others and keep track of all your own reuse code, with forward portability between versions.

If you don't want to install a third-party software, PM me and I'll send you a code example.

[mike5]

Thanks again. I "abused" your library to get the LVClassLibrary.ParentClass which I was unable to find in the menu.

I hope you don't mind...

Br, Mike

[mike5]

NOOOO!!!!!

LabVIEW Class:Open MethodShort Name: LVClass.Open

Available in Real-Time Operating System: No

Why me?!!!

Does someone know of a solution that works on a Real-Time system?

Br, Mike

[Francois Normandin]

Thanks again. I "abused" your library to get the LVClassLibrary.ParentClass which I was unable to find in the menu.

I hope you don't mind...

Br, Mike

Certainly don't mind...

For your RT problem, you might want to keep the hierarchy in a text file. I remember reading about that here on LAVA where people had the same problem. If not mistaken, Antoine Châlons discussed it. (Might be wrong, but try looking for his posts.)

[K-node]

NOOOO!!!!!

LabVIEW Class:Open MethodShort Name: LVClass.Open

Available in Real-Time Operating System: No

Why me?!!!

Does someone know of a solution that works on a Real-Time system?

Br, Mike

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

[mike5]

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

Thanks for the offer, I thought about this as well, but ideally I am looking for a solution that would not require the developer to explicitly call a function in each implementation of the class. But if I'm forced to...

Br, Mike

Anyhoo, I'll post my Windows only solution tomorrow when I'm back at the office for any other unfortunate soul looking for this information...

Mike

[Francois Normandin]

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

The "Parent Class" property requires that you open a reference to your library (refnum, not object), which you can't do at runtime, so RT is excluded too.

The Get LV Class from Path primitive works on RT, but the hierarchy can only be found, as stated by AQ in another thread Mike mentioned, through hacking the XML. But this solution has not been posted yet, to my knowledge anyway.

[K-node]

The "Parent Class" property requires that you open a reference to your library (refnum, not object), which you can't do at runtime, so RT is excluded too.

The Get LV Class from Path primitive works on RT, but the hierarchy can only be found, as stated by AQ in another thread Mike mentioned, through hacking the XML. But this solution has not been posted yet, to my knowledge anyway.

Maybe I misunderstood the OP. I thought he wanted the name of the class and the names of its ancestor classes not the complete hierarchy of a class, that is, not including its children (descendants).

He mentioned using a dynamic dispatch method, so this up the chain hierarchy would be determined at run time.

Did I miss the objective here?

Kurt

[Francois Normandin]

Maybe I misunderstood the OP. I thought he wanted the name of the class and the names of its ancestor classes not the complete hierarchy of a class, that is, not including its children (descendants).

He mentioned using a dynamic dispatch method, so this up the chain hierarchy would be determined at run time.

Did I miss the objective here?

Kurt

You understood it better than me. Now that I read it again (and your answer), I agree with you. Thanks for pointing this out.

[Aristos Queue]

What's your actual goal? I mean, why do you need the names of the ancestor classes at runtime? What are you trying to achieve? I ask because the reflection stuff works in editor environments, but not runtime environments. We may be able to propose an alternate approach than getting the class name because i doubt you're going to find a satisfactory solution to that exact problem... and we haven't made the reflection API part of the runtime engine because a) it would add to the size of the runtime engine and believe it or not, there is some effort made to keep the thing from becoming ever larger and b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

[jgcode]

...and believe it or not, there is some effort made to keep the thing from becoming ever larger...

lol

[mike5]

Anyway, here is the project/library dependent solution that I promised yesterday:

I hope it helps somebody.

Br, Miha

[mike5]

A bit updated version of that doesn't leave all these open references lying around:

Br, Miha

[The Q]

I am pretty new to LVOOP as well but I found one way to do something similar. I added a dynamically dispatched VI to all levels, but the top level, that looks like this:

The top level passes an empty string out in my case. Each child calls the parent method and the concatenates the strings given in the constant of each. I was trying to mimic the path given in a shortcut menu selection event. Through this means you could construct an array instead of concatenate.

[Zyga]

I was looking for getting ancestry list at RT solution for a while. Found few posts, did some coding - no success. I just reply to this old post as @Aristos Queue asks why would someone need that information. I wish to flatten/unflatten object to other format than xml. Surely this post is a grate start, but still unable to get TD even whole data is there. If flatten/unflatten to xml function can do the job, there must be solution hidden under the hood. 

[Aristos Queue]

@Zyga

Here: https://forums.ni.com/t5/Actor-Framework-Documents/AQ-Character-Lineator-working-draft-version-of-serialization/ta-p/3512840

It's my complete, working flatten-to-anything-unflatten-from-anything serialization library for classes [and any other lv data type]. I forget exactly how the names are extracted, but the functions are in there if you want to use them for your own serialization project. Also, feel free to use the library as it stands. 

[Zyga]

On 9/7/2018 at 2:03 PM, Aristos Queue said:

how the names are extracted

From what I see they are not. Correct me if I am wrong, but this lib enforce "serialize" method to be overwritten and then calls it through whole hierarchy.
Disadvantage of that solution is a need to change inheritance. Ok, but enough of moaning. We will use one of existing solution. Just wanted to point out where retrieving ancestry list would be useful (wonder why this information is not in the class flattened string?).

[shoneill]

A Class knows only it's parent, not it's grandparent before being instantiated.  Dynamic loading of classes prevents knowing this beforehand.

[Aristos Queue]

Quote

From what I see they are not.

Oh, yeah. I forgot about that. There's a whole writeup somewhere discussing why I did things the way I did for that library. It's been a while since I worked on it. Sorry for the wild goose chase.

Quote

(wonder why this information is not in the class flattened string?).

Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data.

Quote

Disadvantage of that solution is a need to change inheritance.

I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included.

[Zyga]

6 hours ago, Aristos Queue said:

Quote

Disadvantage of that solution is a need to change inheritance.

I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included.

Now when I am thinking of it, it sounds obvious. I am possessed by flatten to/unflatten from xml ease of use..

 

6 hours ago, Aristos Queue said:

Quote

(wonder why this information is not in the class flattened string?).

Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data.

Once again, now mentioned it is perfectly plain. For me it is hard to imagine using more than 3-4 inheritance levels, but looking on e.g. VI Server I see it is reasonable to have more than that.

Edited September 10, 2018 by Zyga

[Aristos Queue]

2 hours ago, Zyga said:

Once again, now mentioned it is perfectly plain. 

I learned a lot about serialization from writing my library. Took me 2 years of research and planning. "All I want to do is flatten and unflatten some data and I need a library of 900 VIs to do it?!?!?!!" Yes, give or take a couple hundred. Turns out serialization is really a lot more complex than I ever would have thought when you really get down to the core. 

Bloating the string is one of the most fascinating issues, something I totally ignored when I created the original flatten-to-string behaviors for LV classes. To flatten an object, you obviously need to record the type. But what about an array of objects? Do you need the type for every element in the array? Yes, if the array is heterogenous; no if it is homogenous. Can that be factored out? Depends upon what you plan to do with the string! If you're always going to start at the front of the string and unflatten all the data then you can factor out lots of stuff because you have context for the remainder of the string. But if you're going to fly along the string and find subportions to pull out then you need every subportion to be a complete record. "I have an array of 10000 objects. I need only 1 of them." That's a real serialization requirement and it has severe impact on the format of the string itself! 

Formatting for localization, formatting for versioning, formatting for different encodings, formatting for transmission (requires more redundancy in the data), pretty-printing for human readability... it's a mess. 

The one main takeaway I had from my project? I support trade embargoes on any nation that tries to use a comma for a decimal point. I know... Britain and the USA are outliers here, but, seriously, it's called a "decimal point"... stop putting a tail on it! I can deal with two different systems for units. I can deal with myriad ways to format a timestamp (even different calendars). I'm supportive of arcane Unicode encodings so that every language ever can be recorded. But I hit my breaking point on commas as decimal points. Why would I want to live in a world where I can order a 1.125 meter steel beam then be charged for delivery of something over a kilometer long?!?! This table should not exist. Yes, my library provides support for such abominations, but it was while adding that feature that I became a strong proponent of cultural hegemony! 

[PaulL]

On 8/12/2010 at 10:50 PM, Aristos Queue said:

b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

The attached file extracts the relevant slides from a presentation I made at NI Week presentation 2012 that presents just such a case. (I left the slide on Transition Execution Sequence at the beginning of this selection because of the reference.)

The hierarchy can be determined at compile time and stored (not so robust), or at run-time using a couple somewhat complex approaches (adding code to the classes to derive the hierarchy, or attempting casting and see if it fails). Reflection would provide a solution, I think. (The hierarchy could still be determined once at the beginning of program execution.)

TS8237_Lotz_ReflectionExtraction.pptx