Manage COBOL Value Types - What's That Then?

Manage COBOL from Micro Focus not only support classes but also another, very interesting data type called a "Value Type". Here is what you need to know about them:

Value Types are a lot like classes, but they behave in some interesting and distinct ways. First off, let's look at how we define them. Here is a value type (the sourceformat thing is just there to make COBOL not use the 80 column formatting rules):

      $set sourceformat(free)
valuetype-id Burt.
    01 dog string.
    01 cat string.
end valuetype.

This looks just like a simple class except that is has 'valuetype-id' rather than 'class-id'. The following would define a similar class:

class-id Beth.
    01 dog string.
    01 cat string.
end class.

But Burt and Beth are quite different. Here is an example of a difference:

class-id Jane.
    01 a type burt.
    01 b type beth.
    method-id main static.
*      This will work
       display burt::dog
 
*      This will raise a null pointer exception
       display beth::dog
    end method.
end-class

What is going on here then? Well, Burt is a value type whilst Beth is a class. When they are fields, value types are automatically initialized using the default constructor. There is no need to construct them before use unless you want to use a non default constructor.

class-id Fred.
    method-id main static.
      01 a type Burt.
      01 b type Burt.
      procedure division.
      set a to new burt
      move "colly" to a::dog
      move "tabby" to a::cat
      set b to a
      move "terrier" to a:: dog
      display "a dog is " a::dog " a cat is " a::cat
      display "b dog is " b::dog " b cat is " b::cat
      if a::dog equal "terrier" and
         a::cat equal "tabby"   and
         b::dog equal "colly"   and
         b::cat equal "tabby"  
          display "PASS"
      else
          display "FAIL"
      end-if
    end method.
end class.

In the above code we can see the other big difference with value types, they are not reference types. The code:

    01 x as type Beth.
    01 y as type Beth.
...
   set x to new Beth
   set y to x

Will result in x and y referring to the same object. However:


Will result in x and y being different instances of value type Burt. This is because when we assign something to an existing instance of Burt we make a copy of it. The same thing happens when we invoke a method with value types are arguments.

    method-id aMethod.
    procedure division using by value x as Burt.
...
    end method.
...
    01 y as type Burt.
    invoke aMethod(y)

In the above code, inside the method aMethod, x is a different instance of Burt to y. When the invoke happens, COBOL makes a copy of y and uses that copy inside the method. Now let's look at this:

Here x in the method is the same instance as y because the procedure division uses the argument by reference. However, the result is subtly different to if we were using classes instead of value types:

* Block 1: with a value type





In block 1 setting x to a new Burt will have no effect on y, because x is a reference to the value type passed. In block 2 setting x to a new Beth will also set y to that new Beth object because we are passing a reference to a reference to an object.

Other Things To Think About

1. You cannot extend a value type. They are sealed/final.
2. You cannot have picture clause and group items in static or object storage of value types.
3. Value types do not need to be garbage collected as separate object. However, they are only in scope for the method in which they are defined is they are defined as local. However, one must not rely on this behaviour.  Use try/catch/finally instead.
4. It is bad practice to define a finalize on a value type.
5. In many situations they will offer performance advantages over classes and objects. This is especially so for .net Managed COBOL.

CodeProject