Virtual Class

A VirtualClass is a class that doesn't formally exist within the framework of the programming language. It exists as word, as concept of a class and a number of related functions or methods in the framework of the LopLanguage. -- HelmutLeitner

The first example builds on the concept of an operating system, short "System". Usually there is no formal object or class that represents a "System", but there may be a number of related functions or methods:

     SystemGetName(pName)
     SystemGetVersion(pVersion)
     time=SystemRetTime()
     SystemSetTime(time)
     SystemGetUserName(pUserName)
     SystemGetLanguage(pLanguage)
     ...

In LOP one thinks about such objects as being real. An explicit reference is not needed, because there is usually only one operating system the program interacts with. So "System" refers to an implicit default object.

The second example shows a class "Word" whose objects are referenced by their names. Think of a dictionary application where you might talk about:

     WordGetMeaning("software",pMeaning)
     WordGetType(word,pType)
     WordGetOrigin(word,pOrigin)
     WordSetPronounciation(word,...);
     WordCreate("Wiki")
     WordDel("VirtualClass")
     ....

This VirtualClass has no formal class definition, it may be implemented e.g. by using a database or a hash table structure. The object reference is just the name of the word and not the normal object reference of the programming language.

The third example is a VirtualClass that is not implemented for some reasons in a single module (class, namespace, package) but is distributed among a number of modules, even among projects. Think of all image related functions you may have:

functions to create and access an image, perhaps device and platform independent. E.g. ImageCreateWidthHeightBits(...).
functions to display or draw an image, usually device or platform dependent. E.g. HdcDrawImage(...)).
functions to fill an image with data from dozens of different image file formats (JPG, TIF, GIF, BMP, TGA ...). E.g. ImageCreateFile_GIF(...)
functions to aquire images from various sources (e.g. TWAIN). E.g. ImageCreateScanner_TWAIN(...).
functions to do image processing in a project independent way (e.g. build a histograms). E.g. ImageGetPixel(...), ImageGetHistogram(...)
functions to do image processing in a project dependent way (e.g. OCR). E.g ImageGetTextOcr(...).
...

All these functions are tightly related to the Image object and could be theoretically implemented using a single powerful Image class. But they never are for lots of reasons. But using Thelop names we can go farther than the programmers that implemented all this functionality. We may present the API to the programmer (to the user of the API) as if it were a single class Image, a VirtualClass. We can do this by using the "Image" word and implying that this word represents a *real* computer world object that is more abstract and general than what we are allowed to produce within our implementation constraints.

CategoryThelop