Managing Objects in Causeway

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 51

Introduction¶

Managing one’s code is something that often comes last in the list of priorities for the lone system developer. When working in teams, certain standards are often laid down to help the team develop together. In the modern Windows development environment (which is object-orientated by nature) object management tools are available in a number of different forms. These are often the most expensive parts of a toolkit — particularly for multi-user environments.

In this article I take a look at some of the problems I have run into in using Causeway for Dyalog APL, which has no built-in object management. In a future Vector I will be reviewing JAD SMS which is an object management toolkit for APL*PLUS II v5. We hope to review other such systems (including non-APL systems) in future issues of Vector. This will end in a proposal for what functionality is required to manage objects effectively in an APL Windows environment.

Upgrading Causeway¶

Causeway is a method of defining Windows applications that can be implemented on any APL platform. The advantages of using this generic and portable platform are many — and of course there are also disadvantages. I am going to talk about one of the disadvantages of Causeway — upgradeability.

The features I am referring to here have occurred in upgrading Causeway releases within Nestlé in versions of DyalogAPL up to version 7.1.2. Because Causeway is not part of Dyalog APL, but an extra layer of APL code which interprets your Window definitions, you often have to upgrade the two together or at different times. One of the great advantages of Causeway — that it allows the user to hide mistakes in the Gui of the interpreter and fix them with workarounds — is also its downfall — when the interpreter writers fix the problem the Causeway code often needs readjusting.

Normally when faced with upgrading just an APL interpreter I would hope that the job is reasonably painless: take backups of everything — install the new version — check all my workspaces still work — if they do forget all about the previous version and see if there’s anything new that’s worth using. Sometimes the workspace format changes (but the old format still loads) and newly saved workspaces must be loaded in the new interpreter — in a multi-user pc environment this may mean that careful synchronisation of the upgrade is required across a number of pcs/network servers. But as long as this is done with reasonable care then problems are normally few and far between as long as the interpreter itself has been thoroughly tested.

Causeway itself is written in DyalogAPL. It resides in, and is called within, every workspace that requires it. It is not ideal (as with any utility code) to have different versions within different workspaces. Thus, when you get a new release of Causeway you will probably want to test it in a number of environments, and then when you are happy you will want to install the new version (for new developments) but also upgrade existing code onto the new version — to prevent confusion — to help support and potentially to ease existing bugs.

Unfortunately Causeway exists inside and outside your workspace in a number of ways — this makes the upgrade path treacherous at best. The first step is obviously to upgrade the Causeway code. This is pretty simple, something like )copy causeway should do the job and replace the old Causeway code with the new. With any luck the Causeway developers will have documented what has changed and there may even be some functions that aren’t used any more — )erase these if you are feeling really brave.

In a simple world the above would be the end of the story. You would test the workspace out, find it still works OK and go home happy. Unfortunately, other changes are often required.

The Causeway form-definitions are held in nested variables within your workspace. Due to progress, design changes etc. (remember the current Causeway architecture is fairly new) these definitions are often adjusted, meaning that every form definition requires upgrading. Hopefully you have used some standard naming convention so that it’s easy for you to find all your form definitions. Also with any luck the Causeway developers have supplied the code to upgrade each form definition automatically. If this is true it should be easy to convert them all.

Sometimes, there are changes within Causeway that require that form definitions are analysed to see if they use defunct procedures/concepts. This will probably have to be done manually — although I would advise you write a little routine that searches the forms for any such ‘problems’ and tells you which ones need attention. These sorts of changes are quite common. Recently a Causeway event was removed from all the supplied objects — the PC/Post Create event. This event could be used to run code following the creation of the object. Thus any code within a form relying on this event had to be modified. In this example this code could usually be moved onto the CR (create event) or moved onto a different object.

More advanced users of Causeway may have also modified or extended their Causeway environment in a number of ways. They may have added styles, they may have added objects, they may have added global events, they may have added column types for the grid object etc. If changes like this have been made, then much greater care is required — following the above path when upgrading will end in tears.

Adding/Changing Styles and Objects in Causeway¶

Causeway maintains a list of styles in the global variable ∆styletab. Any modifications you make to this table will be lost when you copy in the new Causeway code — thus you should always take a backup copy and re-apply any changes you make to the new version.

Causeway objects are held in a large global nested variable called ∆classtab. Once again modifications will be lost when the new code is copied in. Fortunately classes can also be held externally to the workspace in APL sharefiles. The best path to upgrading the class table is not to take a copy of the class table but to make a note of which classes it contains before copying the new Causeway workspace in, and then rebuild the class table from scratch from the external file copies of the classes.

Unfortunately, in the last few Causeway releases, changes have been required to classes when upgrading from one version to another. Causeway comes with a standard set of classes so these should all work — you can then generate the file copies of the classes from these. For those classes that you have created/modified you will need to redo any modifications by hand and then save the classes to file. The new set of class files can then be used to regenerate all the class tables in all the upgraded workspaces. Because of this I advise that you track quite carefully when you are using standard Causeway objects and when you modify/create your own. This will enable you to perform the upgrade in a much more controlled manner.

Adding/Changing Events in Causeway¶

Once again the set of events that causeway objects handle and monitor is held in another global variable … ∆events

If you added/modified these then you should take a backup copy of this variable before you upgrade and then update the new copy with any of your changes. This is rarely necessary now because Causeway classes now support internal/local events which is why you often had to add events to the list to support particular objects (e.g. grid-specific events). This type of event is now held within the object definition itself and not globally in the events table.

For the Future¶

Causeway has been designed in such a way that it is an ‘open’ product. This encourages modification and creation of your own objects. Indeed, this openness is one of the strengths of the product. But when upgrading, these user changes are often lost, or cause errors which may well be difficult to debug or fix without advanced knowledge of the architecture. The root cause of this is the use of large nested global variables to hold the extensible parts of the Causeway architecture. This means that when upgrading, you need to re-hook your extensions into these core variables — often having to check for architectural changes along the way — and then perform upgrades from your extended versions. Also, being a developing product it is still at a stage when concepts are added/removed — meaning that if you upgrade you must re-adjust your application code. This aspect should not be a problem as the product stabilises.

The Causeway architecture forms the core of all Nestlé’s DyalogAPL systems. Because support and development analysts are often the same people, it is too confusing and dangerous to allow different versions of the architecture to co-exist in a production systems environment — thus whenever the Causeway architecture changes many systems need to be re-adapted, so upgrading needs to be as seamless as possible. At the moment it takes too long and is too complex a task.

The basic Causeway architecture is only partially the cause of these problems. People who have been using Causeway would not have typically run into these difficulties unless they have been customising the system themselves. This customising is what we in Nestlé see as being the real strength of the system, but unfortunately it is also a disadvantage when there is no effective object management environment. With an object management environment in place upgrades could be handled far more transparently, older versions of objects would be kept — meaning upgrades could be made where appropriate/convenient — and different versions of the Causeway code could be maintained in parallel. So what is it that makes an effective object management tool? Future Vectors will hopefully tell us ….