Collection and Map Classes for OOABL

In developing a foundation framework for Object-Oriented ABL, it seems natural to consider creating a set of Collection classes since they have a broad utility in OO design in other languages. It also seems natural to consider imitating the Collection classes in Java since that is a tried and true implementation into which there has been a considerable investment of thought and effort. However, while Java Collection classes need to use relatively low level constructs like arrays and hash tables for implementation, in OOABL we have temp-tables, which not only provide a very easy and flexible way of maintaining a set, but which has the significant advantage of being open-ended (unlike an array) and having an automatic extension to disk. This use of temp-tables is likely to lead to a number of appropriate differences between a good OOABL implementation and the Java implementation.

Since Java Collection classes are a class hierarchy in which there are progressively more assumptions about the set, it seems likely that the use of temp-tables will obviate the need for some of the intermediate classes since there is no advantage to a defining a degenerate version once one is already using full featured temp-tables. I.e., if one has a concrete implementation using temp-tables, providing an alternate concrete implementation that also used temp-tables, but included less capability would be pointless. An example of this kind of distinction is that some Java Collection classes only provide for forward navigation in the Collection, but all of the OOABL classes described here provide both forward and backward navigation because it is trivial to include (i.e., Iterator versus ListIterator).

Download document to continue reading

Downloads include documentation, the collection and map classes, and test code for validating function.

Requires version 10.1A

For services related to this material, see my website.


AttachmentSize
CollectionClasses.pdf118.72 KB
CollectionClasses.zip9.74 KB
CollectionClassesTest.zip31.94 KB

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

JSON Parser

Is there a publicly available JSON parser for OOABL which uses these classes?


The List Class Destructor.

As a followup to my previous post, I have now written (and am currently testing) the JSON parser. One of the objects that I stored in the StringObjectSetMap was a com.cintegrity.Lib.Collection.List. In testing my results, I noticed that my memory usage kept going up with each use of my test program, even though I was deleting the objects I used (at the top level of the program). I finally traced this problem to the List class. The destructor for that class simply emptied its internal temp table. The records in this temp table (ctt_List) contain a reference to class instance (ob_AnObject).

I changed my copy of the List class to contain this destructor:

  destructor public List():
    for each ctt_List:
      delete object ctt_List.ob_AnObject.
    end.
    empty temp-table ctt_List.
  end destructor.

and my memory problem has gone away.

The XXXObjectSetMap classes delete the contained Objects. Is there something about the List class that implies that the objects referenced internally should not be deleted when the List itself is deleted?

Thanks for the help,
Brian White


JSON Parser

I note with interest that you have created a JSON parser using the Collection and Map classes outlined in this thread. Is there any chance that your parser is publicly available? Willing to share? If not, is anyone aware of a publicly available JSON parser for OOABL?

Thank you.


tamhas's picture

Who does deletion?

My instinct is to think that the list object should not be deleting the objects because it wasn't the list object that created the objects. They should be deleted by whatever created them on the theory that an object's lifecycle should begin and end in the same place. I can certainly see cases where the list itself has a lifecycle and when that is done one knows that one can delete everything, but perhaps that should be a different method, not just the destructor.

E.g., suppose the purpose of the collection is to identify a set of candidates and that one then selects an object for action and then no longer has a need for the remainder of the collection. One wouldn't want to delete all objects at that point because that would delete the selected object as well.


Collection & Map Classes -- A Question

In the pdf that accompanies the Collection & Map Classes it states that the collections will currently be used only for true objects. That's a serious limitation for the Map related classes. I understand the need for the restriction, but I was hoping to use the StringObjectSetMap class to house a set of heterogeneous data parsed from a "stringified" JSON object (JavaScript Object Notation, see http://www.json.org for details.). Should I create a set of simple primitive data type Object wrappers in order to accomplish this? I know the key type to be string, but the value type could be anything from the primitive types to child Collection objects.

Any suggestions?

Brian White
Raleigh NC


tamhas's picture

Collections of ??

There is a certain inherent limitation in current ABL, including 10.1B, in that there are neither object versions of primitives nor generics. I made a decision when doing this work to limit the classes to only dealing with objects, waiting to see how common the need for other types of collections might arise and, whether or not one really needed a collection object for those other cases. After all, there are certainly cases where one might have a "collection" of strings where a simple temp-table is actually a good implementation because the "collection" can be managed within a single object, i.e., there is no need to pass the collection around independent of the context.

Which said, it sound like your problem is a little different because what you have are heterogeneous objects ... some of which aren't objects at all. In that case, I would ask yourself which of four implementations best suited your needs.

The first is that if you are going to convert everything to a JSON object, you really have all strings. If that is the case, you can either use a simple temp-table within an enclosing object for the purpose or you can clone the collection class to include the string target case.

The other three are based on leaving the objects in their native form, rather than converting them all to string form.

The second would be a simple temp-table with multiple fields for the different" object" types you needes ... if you need to handle a string, put it in the string field; if you need to handle an integer, put it in the integer field, etc. Presumably, this also includes some kind of type indicator so that you know which field to interrogate.

A third would be to create your own primitive equivalence objects and assign the string to String, etc. This would let you use the existing collection objects. Of course, this also implies needing some way to know how to cast the Progress.Lang.Object back into the correct type. Of course, if you created only a string primitive class, you could also use this for the JSON strings.

The fourth would be to create a special class for the purpose which could contain multiple types of values. This would allow you to use the existing collection classes.

I will note that I hope to be releasing a new version of the collection and map classes in the not too distant future. I need to wait for 10.1B FCS and completing them is complicated at the moment by having had my workstation crash :( and scheduling around the holidays. The new version will be a bit cleaner internally through the use of properties and I will be encapsulating the internal temp-table in a ProDataSet so that one can set Tracking-Changes and thus detect which objects were changed aftet the construction of the original collection. RIght now, I can't promise when this will get posted, but it shouldn't be very long.