Notifiers w/ Class

[Norm Kirchner]

I have an architecture that requires a notifier to be part of the class data.

This is so that wherever the class gets sent to, it can send itself back via what would now be waiting on the created notifier.

(I know there are other ways but roll w/ me on this)

So would you think that it's a bug or rather should be illegal to embed a notifier which has the data type be that of the class that it is contained within?

I understand this feels a little chicken-eggy, but I see no real reason why I should be prevented from doing this.

(because every time I do try, it breaks the class)

See the attached code and simply replace the data type within the notifier to be a variant and everything is ok.

Open project, look at class data def, observe simple data structure, open write notifier.vi, observe dead wire, open typedef and replace

Download File:post-208-1229833042.zip

So before I harass an AE that I might actually run into on the elevator, I thought I would see what y'all thought.

[Tomi Maila]

LabVIEW doesn't allow using recursive data types. I wrote an article on it a year ago on ExpressionFlow. What you can do is to make the notifier type to be of parent class or LabVIEW object. Then simply cast the notifier data to more specific when the notifier is received. Also note that you should use the new Wait on Notification (from Multiple) With Notifier History function in class method vis and other reusable code to avoid possible incorrect behaviour or in worst case application freeze conditions.

Cheers

Tomi

[Aristos Queue]

1. From a logical point of view, you are correct that no there's no reason that LabVIEW should disallow a notifier of a class being inside the class itself (or a queue or an array whose default value is an empty array, or a datalog or indeed any other refnum type with the class embedded inside it). After all, although the data *type* may be recursive, the data is not.
   
2. From a language simplicity point of view, it's just a lot easier to explain "LV does not allow a class to be used as part of its own definition." than to go into the intricacies of why an array would have to have a default value of zero length, or try to puzzle out the error list window when such a circular class breaks. This is ESPECIALLY true when we start talking about circles of greater than one step (i.e., A includes B which includes A).
   
3. From a language implementation point of view, there are plenty of performance shortcuts that can be made when loading a class into memory if we assume that all classes that are not broken are ones that do not include themselves in their definitions. Class unloading is complex enough without having to try to find "in any given circle of classes, identify which one is the reference one and allow it to unload first".
   

Because the need for circular definitions is particularly rare compared to the total number of classes in the world, and because such need is typically encountered by advanced programmers, and because such programmers can and do stumble upon the idea of using the parent class in their child class definition to achieve much the same effect, points of view #2 and #3 trumped #1 during LV's design process.

[Jim Kring]

I've noticed problems when the class data contains a queue/notifier/event reference that includes the class data type -- this is a recursive type definition. You should (do as Tomi suggested and) make your Notifier use a generic LVClass reference and then upcast it to the more specific type after you receive the notification. This solution works very well and is how we solve this problem at JKI.

[CodE]

I am just adding to this old thread.

I was trying to use the same type of architecture in my project, until I realized that LV is not allowing me to use notifier of Class datatype inside the Dynamic Dispatch VI. But as posted here, LabVIEW now supports recursion, so shouldn't this kind of architecture be allowed?

By the way, I still didn't get a clear picture of why this type of architecture can't be allowed in LabVIEW.

[jerl]

If speed doesn't matter, it's perfectly valid to have an Variant containing the Class / DVR to Class / Notifier with Class / etc... in class data. You have simply to convert to / from Variant in the accessor methods.

Edited March 21, 2011 by jerl

[ceties]

I am just adding to this old thread.

I was trying to use the same type of architecture in my project, until I realized that LV is not allowing me to use notifier of Class datatype inside the Dynamic Dispatch VI. But as posted here, LabVIEW now supports recursion, so shouldn't this kind of architecture be allowed?

By the way, I still didn't get a clear picture of why this type of architecture can't be allowed in LabVIEW.

LabVIEW supports recursive CALLS but not the recursive DATA TYPE DEFINITION which is what they discussed here. To help you answer why continuehere