Serialization by "Generic Object Serializer" of classes that implement an interface

logmanoriginal / JSONtext-Object-Serialization

Object serialization strategies for JSONtext

BSD 3-Clause "New" or "Revised" License

6 stars 3 forks source link

Serialization by "Generic Object Serializer" of classes that implement an interface #17

Closed klopsquark closed 3 years ago

klopsquark commented 3 years ago

Hi, first of all, good job!

Then I have a question about the intended functionality.

Can classes that implement an interface be serialized with the "Generic Object Serializer"? (LV2020)

I have been digging for a while and found that interfaces are identified as "parents", but then cannot be processed further correctly.

Thank you very much!

klopsquark commented 3 years ago

Some more details...

logmanoriginal commented 3 years ago

Thanks for reporting this issue!

Looks like interfaces are detected as part of the inheritance hierarchy, which is a problem because they don't have private data controls. I'll setup a VM to do further tests, perhaps there is an easy way to detect/ignore interfaces. This is certainly a bug.

klopsquark commented 3 years ago

Hello,

here is some more information. I dug a little deeper.

The problem arises in another library: "LabVIEW-Composition"

Enclosed how I temporarily solved it:

LabVIEW has no function to recognize an interface. The only option in your active implementation is to take advantage of the error if no * .ctrl can be found. Then it's probably an interface.

logmanoriginal commented 3 years ago

Okay, I finally got a VM up and running.

here is some more information. I dug a little deeper. The problem arises in another library: "LabVIEW-Composition"

I'm happy to see you digging through the code. Any feedback is appreciated :)

LabVIEW has no function to recognize an interface. The only option in your active implementation is to take advantage of the error if no * .ctrl can be found. Then it's probably an interface.

Here is another way, which doesn't rely on the error output. It does a lookup on all VIs in memory (which includes private data clusters of classes).

Unfortunately there is no way to unit test this in LV2017, but it seems to be working in LV2020.

logmanoriginal commented 3 years ago

I updated the underlying library. Here is a draft release with the new package: https://github.com/LogMANOriginal/LabVIEW-Composition/releases/tag/untagged-62d37490c364dfe2524f

Let me know if this works for you.

klopsquark commented 3 years ago

I have tested your modifications and it works now as far as I can see. Thank you very much.

klopsquark commented 3 years ago

Okay, I finally got a VM up and running.

here is some more information. I dug a little deeper. The problem arises in another library: "LabVIEW-Composition"

I'm happy to see you digging through the code. Any feedback is appreciated :)

LabVIEW has no function to recognize an interface. The only option in your active implementation is to take advantage of the error if no * .ctrl can be found. Then it's probably an interface.

Here is another way, which doesn't rely on the error output. It does a lookup on all VIs in memory (which includes private data clusters of classes).

Unfortunately there is no way to unit test this in LV2017, but it seems to be working in LV2020.

Probably you can use the community version of LabVIEW 2020

logmanoriginal commented 3 years ago

Probably you can use the community version of LabVIEW 2020 I have added a LV2020 branch which includes some tests for it.

Thanks for the feedback! I'll push the official release.