What an object-oriented MUMPS could look like, without breaking existing code

A little idiomatic support for the OO paradigm is something I’d love to see MUMPS embrace in the future. This is not to say that you can’t write OO code in MUMPS ’95–you can even write OO code in assembly language–but, the syntactic sugar would be nice, as well as the scoping protection and encapsulation this would give. The introduction of the dot-notation paradigm would lend itself very well to creating clean new API libraries. Some of you may not know, but the dot-notation API is used by some MUMPS vendors for calling out to external (non-MUMPS) routines.

We’d add a few new things:

  1. Overloading the NEW command so that it can also be a unary operator. This will allow operations such as:
    set myCar=new $$Car()
  2. Adding a $OBJECT() intrinsic, which would take two parameters: a variable name and a type name.
    $OBJECT(variable,type)

    would return a true value if the node referenced by variable (which can be a global variable or a local, either could include subscripts) matches the type defined by type.

  3. Adding a this keyword, which would return the entire current object.
  4. Adding conventions to the language. Any NEW commands at the top level of a routine would define instance variables, and the top-level routine without any tag specified becomes the default constructor for an object.

The main thing I’d like to see, though, is the ability (shown in the hypothetical sample below) to store entire object instances in MUMPS globals and retrieve them later:

;; when tag and routine are same, use the default constructor
Car
 new color,doors,started 
 set color="",doors=0,started=0
 quit
;; overloaded constructor (limitation: 
;; you could only overload the constructor once)
Car.Car(color,doors) 
 set this.color=color,this.doors=doors
 quit this
;; procedure method
Car.Start 
 set this.started=1
 write "Car started",!
 quit
;; procedure method
Car.Stop 
 set this.started=0
 write "Car stopped",!
 quit
;; extrinsic function method
Car.Color() 
 quit this.color
;; extrinsic function method
Car.Doors() 
 quit this.doors
;; extrinsic function method
Car.Started() 
 quit this.started

TestCar
 ;; new as a unary operator as well as a command
 new wifeCar
 set wifeCar=new $$Car("blue",5)
 new myCar
 set myCar=new $$Car("silver",4)
 ;; we're now going to store myCar and wifeCar in subscripts 
 ;; of the ^persistentCars global
 set ^persistentCars("John")=myCar 
 set ^persistentCars("Miri")=wifeCar
 ;; $object(variable,object) would return null if "variable"
 ;; is not of type "object"
 new memCar
 if $object(^persistentCars("Miri"),Car) do 
 . ; this use of the new operator will fail 
 . ; if ^persistentCars("Miri") is not a Car
 . set memCar=new $object(^persistentCars("Miri"),Car) 
 . ; we can now access Car's methods from memCar
 . do memCar.Start 
 . if $$memCar.Doors()>2 write "family car!",! else write "coupe!",!
 . set ^otherPersistentCars("Miri")=memCar
 else write "The global did not contain a valid Car",!
 quit
Advertisements

3 thoughts on “What an object-oriented MUMPS could look like, without breaking existing code

  1. Been done before?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s