Use class types

Assume that book.com wants to provide one bulletin board per book for posting book reviews. Implementing each as a singleton object of imop:api.org/service.IBulletin is unfavorable. One would prefer to create the object from a common class type, such as the meso:tools.Reviews class above. The class implements the imop:api.org/service.IBulletin interface, and thus objects instantiated from it can be operated through that interface from the Internet. Notice that the class type belongs to the meso: type scheme, which is accessible only within the local Meso runtime. In fact, IMOP does not support class types at all. One may use a local class type to create a new object that is accessible through IMOP, but the class type itself is not publicly visible.

We made this design choice because a publicly defined class type will confuse people about where its object is created. It may be either at the remote host where a class's definition is located, or at the local machine where a new expression is evaluated. More importantly, if a class type is publicly defined in the Internet, people will want to create derived classes from it. But this cannot be done without transferring program code over the network, since otherwise a derived class will not have complete implementation code to instantiate an object. In order to keep IMOP simple and programming language independent, we choose not to support class types in IMOP.

To create a new object dynamically, one may use a factory method to instantiate it from a local class type. In the example above, the getReviews(string) method in imop:book.com/mgrs.ReviewManager works like a factory method, creating a new meso:tools.Reviews object when necessary. The following figure shows the IMOP messages exchanged for invoking getReviews("1234567890") on the ReviewManager object:

The returned UTL imop:book.com/obj1a2b3c is dynamically generated from the object of the Reviews class. Nevertheless, the descriptor reflected from the UTL shows no signs of the Reviews class. It looks just like a normal singleton object that implements the imop:api.org/service.IBulletin interface.