Jump to content

Nested collection with interfaces


Recommended Posts

I had some time to learn about new interfaces and finally I could implement my collection class as I had envisioned. I didn’t want to use iterable and iterator names, because I thought that would have been too bold a claim.

The original version of the collection class was (and is) used as a collection of sequence steps. Each element can be either a sequence command (send message, wait timer, wait complete etc.) or another collection of commands (sub-sequence). That’s the reasons for the labels and search method. Otherwise it is just a fancy (Rube Goldberg) array.

Next method is recursive and it steps through all elements in the collection. Execute is only method, which requires override.

For now, it’s at least an exercise in new interfaces. I don’t know if it’s useful enough to be in the code repository, but I can polish it up if needed.

 

--
Marko H
Certified LabVIEW Architect
www.optofidelity.com

Iterable Collection LV2020.zip

Link to comment
  • 1 year later...

Updated version.

Simpler design with single interface class for a collection and items in collection. Items can be objects of any class which inherits from Collectable interface and of course by then items can also be another collections.

Next method iterates over items in order on insertion. And Next can also be overridden to create a generator.

Collectable interface forces child class to implement data accessor methods (Read, Write) and to store the necessary class and object data.

Execute method has been removed from interface as it is not really a method of a collection. 

 

 

Iterable Collection 2.0 LV2020.zip

Edited by Marko Hakkarainen
Fix Label data access scope
Link to comment

I don't think this is a good use case for interfaces. Not so much the test stuff, just as a "Collection".

As an aside; pedantically and academically, the difference between a List and a Collection is that a Collection is unordered so what you technically have is a List - although many use the terms interchangeably. What this means in practice is usually a List is implemented as an array (arrays are intrinsically ordered) and a Collection is implemented as a linked-list. So to access a Collection iteratively, Next/Previous must be used.

On 5/18/2020 at 2:25 PM, Marko Hakkarainen said:

Each element can be either a sequence command (send message, wait timer, wait complete etc.) or another collection of commands (sub-sequence).

That's not a desirable limitation for collections. IMO, a generalisation of collections should not limit types.

On 12/18/2021 at 5:57 PM, Marko Hakkarainen said:

Items can be objects of any class which inherits from Collectable interface

This is also undesirable.

A while ago I wrote a List class which was modeled on the functions in the Delphi collections class. It doesn't implement Next/Previous like here but it could be added trivially and wouldn't have the above limitations.

As a specific "Array of Test Sequences" you are OK but it's not general enough for a generic "Collection/List" class.

Link to comment
  • 2 weeks later...

The OCD part of me is screaming over the naming. "Collectable" is an object that can be collected. Why is it also the collection? IMO, a interface called Collectable that provides access to an array of Collectable doesn't make much semantic sense. I notice that in your first version, Collection inherits from Collectable. That also seems odd, but I think maybe you did that so that your Collection class could be part of a Collection.

If you separate Collection and Collectable into different concepts, then Collectable seems to have little value. LabVIEW has a common ancestor for all classes, so if you wanted to create a "generic" collection then it should just hold an array of LabVIEW Object. (Or possibly even variant...) Of course, that introduces some complexities with type parsing, so multiple <SomeType>Collection classes might be preferable.

The way you have defined Collectable typedef and are using it in all your private data controls just doesn't really feel right. You've basically defined a class, come up with an odd proxy/composite sort of thing where the encapsulating class owns the data.

I personally think it feels like you are putting too much into one interface, and then when you refactored you tried to consolidate even more into it. To accomplish what I think you are going for, I do believe you will have a common interface across these classes, but I'm not sure if Collection or Collectable is it and, in any case, you should probably be creating more than one! Remember that classes can inherit from multiple interfaces!

Some ideas...

Iterable, Test Step, and Collection all sound like separate interfaces to me. (Collection may not even be of much value...)

A Test Sequence is a Test Step that contains other Test Steps... sounds like a class that inherits from Iterable, Test Step, and Collection. 🤔

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Mahbod Morshedi
      Hi All,

      I m trying to build a software, and data management has become too complex. In short, it is acquiring data from three channels and doing some calculations and then showing and reporting that data for the user to make a fitting decision. The user then, can save the file and import the saved worked-up file later to view or manipulate.
      The data consist of three interdependent data set, and so far, I have collected the dat as an array of clusters (size 3) for three sets and kept user input data in the same manner. I am also using a simple "producer/consumer" design. However, I think that may have been a mistake, and I might be able to do a better job using either actor or QMH design, especially since I need to think about adding the acquisition part (which is not yet developed). The thing is that I have not used oop before at all and am not quite sure if this is the correct approach and how should I bundle my data. Considering that the data (not all but some) need to be accessed by other classes if I goo with oop.
      For example, should I keep the data as separate class data and use methods for override or keep it as an array in the parent class and use static methods and only use child classes for graphing. These are the type of questions I am struggling with. Also, can anyone help me decide between DQMH, Actor or just standard Producer/Consumer patterns, please? I am completely lost.
      Thank you in advence.
       
      This is how the front pannel looks like:

      And this is the data set for the system (which I am keeping as an array) there will me more data added to this as the capabiliy grows.

    • By cyro2015
      Hi,
      I tried to create a template based on OOP for QMH. During development I have been confronted with infinite crashes of LabVIEW so I decided to slow down with this project and open it to the community. I finished my working example and stopped for now.
      So if anyone is interested to play around with the code, see attached ZIP file (LV 2020).
      Cu,
      Peter
       
      MHT.zip
    • By Zyl
      Hi everybody,
       
      I'm running into something I don't really understand. Maybe you can help me here !
      I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions.
      In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions.
      In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem.

      But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks !

      The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library.
      I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection...
      Am I missing something ?
      DVR Private POC.zip
    • By Brains
      Hi,
      Does anybody know the best way to make a copy of a byref object (open gds v4) at runtime and pass all the attributes values (including inherited attributes) to the new object?
      Thank you!
      Craig
    • By GregFreeman
      I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
      Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
      For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
      I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.