Getting started with OOP for User Language programmers

From m204wiki
Revision as of 22:10, 4 September 2010 by Alex (talk | contribs) (Checkpoint save)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Background

So, you're a User Language programmer and you're thinking about learning object-oriented programming:

  • Rumor has it you can be a more effective programmer if you use object-oriented techniques.
  • You're tired of feeling inferior to object-oriented programmers because they speak a language that you don't understand but sure has heck sounds impressive.
  • You use Sirius Software products and Sirius has announced that all new User Language functionality will used object-oriented syntax.
  • “Object-oriented” looks better on your resume than “User Language”.
  • You just want to learn something new.

Unfortunately, most User Language programmers' first experience with object-oriented programming is painful and bewildering. Often it comes in the form of a VB.Net or Java class where the terminology flow freely from day one. Even worse:

  • Classes often emphasize how one architects an object-oriented application. While this might be a logical way to build an application, it's a daunting way to learn a language — like trying to learn ballroom dancing before you know how to walk.
  • Teachers (and books about object-oriented programming) are often enamored with the more sophisticated aspects of object-oriented programming languages, leaving novices in the dust as they're still struggling to digest the simpler concepts.
  • Many object-oriented concepts are inter-related so it often requires plowing ahead without fully understanding the concepts one has already learned.
  • There seems no way to put the concepts learned in a Java or VB.Net class to use in User Language. So, one is either forced to try to work on object-oriented programming in one's free time, or the concepts are quickly forgotten.

Fortunately, there is a way you can learn object-oriented programming, and apply the principles on-the-job from day one!

One requirement for this is that one work at a site where Janus SOAP User Language Interface is available or, at least some of the other Sirius “API” products such as Janus Web Server or Janus Sockets.

First, a quick word about terminology. In English-speaking, as opposed to American-speaking countries, objected-oriented is usually called object-orientated. More commonly, everyone just calls object-oriented programming “O-O”. But then, you knew that.

Mixed case code

So, let's get started. First, if you're going to do O-O programming you've got to write your code in mixed case. No, there is no technical reason O-O code in User Language must be in mixed case but:

  • It's easy enough to do and, even if you don't use O-O, it makes your code look more modern.
  • The industry consensus is that descriptive, often compound words, are better for variable, function, and subroutine names than terse non-descriptive names. For example, %itemNumber is better than %ITMN. While the latter is easier to type, the former is much easier to read. USing %ITEMNUMBER, on the other hand, clearly blunts some of that readability benefit. %itemNumber is written in what's called CamelCase.
  • Sirius Software depends on CamelCase to make their function and subroutine names readable.

Fortunately, it's easy to start using mixed case code. Simply start typing your code in mixed case. What can possibly go wrong? If you're system manager has set everything up nicely for you, nothing. But, if not, you might hot a few glitches that are easy enough to fix:

  • If you use the 204 editor and type in mixed case code and it gets converted to upper case when you hit enter, you have two options:
    1. Set *LOWER at command level. This is a bit of a hassle because now Model 204 commands require holding the shift key down, because mixed case Model 204 command don't work.
    2. Set the SIREDIT user parameter to X'33' (only the X'01' bit is required, but you may as well set some others) before entering the editor. This cause Model 204 to essentially switch to *LOWER mode before entering the editor. Request that your system manager do this for everyone by setting SIREDIT X'33' in CCAIN.
  • If you get compilation errors when you type in mixed case UL, it means that the compiler is not running in case-independent mode. To fix this, you have three options:
    1. Have your system manager set the X'01' bit in the system COMPOPT parameter. This must be done in CCAIN and is probably the best/simplest option.
    2. Change the BEGIN or B statement at the start of the request you're working on to use mixed case, as in Begin, begin, or b.
    3. If you can't change the start of the program, add the line Sirius Case ToUpper (the case of the words, doesn't matter) to the start of the procedure you're working on.

The following is an example of a mixed case User Language program that starts with a mixed case Begin:

 begin
 print 'Hello World!'
 end

The following is an example of an Included procedure that contains a Sirius Case ToUpper directive:

 sirius case toUpper
 subroutine hello
    print 'Hello World!'
 end subroutine

Note that mixed case UL support is case independent so you can write UL statements in an case, and you can refer to Model 204 variables in any case. The following illustrates a little island of mixed case code in the middle of some upper case code:

 SUBROUTINE FOOBAR(%INPUT IS FLOAT)
    %MSG   IS STRING LEN 32
    %TOTAL IS FLOAT
    ...
    if %input gt %total then
       %msg = 'Input value too big'
    end if
    ...
    PRINT %MSG
 END SUBROUTINE

This illustrates that you don't have to convert an entire procedure (or request) to mixed case to take advantage of mixed case UL, though, obviously, in the long-term, it's a good goal to aim for relatively consisten casing in all your code. In the short term, however, a bit of inconsistency will have to be tolerated to get to the point where most or all UL code is in mixed case. Certainly, any new procedures should be written completely in mixed case.

As this example, illustrates, you don't have to learn anything new to enter UL in mixed case (all statements still work the same way) so there is no excuse not to start.

Object-oriented syntax

The most pernicious difference between O-O languages and procedural languages such as User Language (we'll just call it UL from here on) is the syntax. And the biggest syntactic difference between O-O and UL is how functions are subroutines are invoked. Let's start with functions. All UL programmers know how to invoke a function.

First, functions are called $functions (dollar-functions) or £functions (pound-functions) in the UK. $functions always return a value so must either be on the right side of an assignment, input to a subroutine or other $function call, or inside some UL expression. The following example, has a $substr in all three contexts:

 %x = $substr(%y, 3, 10)
 call clever($substr(%y, %start, %len))
 %z = $substr(%y, %len, 1) + 10

As the above example illustrates, and all UL programmers know, a $function can be followed by the $function arguments (inputs) in parentheses with multiple arguments separated by commas.

O-O functions, on the other hand, use a syntax where a function invocation consists of the thing (object, if you will) that the function is operating on specified before the function name, followed by its arguments inside parentheses. Many $functions have O-O equivalents and $substr is no exception: its O-O equivalent is called substring. The following illustrates the use of the O-O substring function by replacing $substr in the previous example with substring:

 %x = %y:substring(3, 10)
 call clever(%y:substring(%start, %len))
 %z = %y:substring(%len, 1) + 10

While this might look strange to a User Language programmer, it uses the most common O-O syntax so can honestly be called O-O programming. So, if you find any $substr call in your system and change it to use substring (moving the first argument before a :substring) you have now done some O-O coding. It's that easy!

To further add to your bona fides as an object oriented programmer, don't call substring a function, but call it a method. In addition, don't call %y just a string, call it a string object. Now you're ready for something more advanced. Say “I applied the substring method to the string object”. Repeat until it feels natural to say it. Congratulations, you're well on your way to becoming an O-O programmer and, maybe even a guru. If you're curious about what you just said:

  • Method is just a fancy word that means function or subroutine or any other called code that does something.
  • Object is just a fancy word for a thingy.

Now, of course, there are many functions available other than just Substring. The functions that operate on strings are called Intrinsic String Methods. You can find a list of the methods at List of Intrinsic String Methods. There are also functions that operate on numbers. The list of these can be found at List of Intrinsic Float Methods.