Nested collection with interfaces

[Marko Hakkarainen]

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

[Marko Hakkarainen]

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 December 20, 2021 by Marko Hakkarainen
Fix Label data access scope

[Francois Normandin]

Hi @Marko Hakkarainen, 

your "Test Labels" example is broken. Accessors (Write Label) is not public. Perhaps wrapping it into a generic Collection constructor method?

[Marko Hakkarainen]

Thank you. "Label" of course needs to be in public scope.

[ShaunR]

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.

[JB_1592]

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. 🤔