ThelopWiki

Wards Wiki Pages / Virtual Object

Difference (last change) (no other diffs, normal page display)

Changed: 1c1,46
Describe the new page here.
A VirtualObject? is an object that doesn't formally exist within the framework of the programming language. It exists as word, concept and object in the framework of the LopLanguage?. -- HelmutLeitner

These examples are trivial. They are not meant to teach something new. They are necessary to explain the term VirtualObject? as it is used in LanguageOrientedProgramming.




The following function calls are without an explicit object reference. The words "World" and "System" represent the VirtualObject?s (no need to explain them).
wtime=WorldRetTime()
wtime=World.retTime()

stime=SystemRetTime()
stime=System.retTime()
Usually programmers would use terms like "namespace" or "toolkit class" to speak about such a situation. But note that in LanguageOrientedProgramming the words "World" and "System" are not arbitrary, they are meant to model real objects. They have to be justified, defined and documented before you are allowed to use them.




The following function calls use more than one parameter as an object reference.

Rewritten (and extended) from the standard C library:
MemClear(p,size)
MemSetChr(p,size,char)
MemCmpStr(p,size,s)
StrCpyMem(s,p,size)
FileCpyMem(filename,p,size)
MemFindStr(p,size,s)
MemFindChr(p,size,char)
The object Mem is represented by a Pointer and Size parameter (and means an arbitrary range of RAM memory). It stands for an object abstraction that does only exist in the mind of the programmer.

Why not actually represent Mem as a object (strictly an ADT) that holds the pointer and size as member variables, and controls access to those variables with methods or access functions?
* Answer one: usually this abstraction is only valid for a very short time, say one or two function calls. So the overhead of an object doesn't make sense.
* Answer two: very often it *is* made an object, but then it aquires a meaning, additional functionality and a name. So it is not the virtual object Mem anymore.

Just an example from a "higher level":
ImageRectClear(image,pRect);
I'mage.R'ectClear(image,pRect);
ImageRectWriteFile(image,pRect,"test.jpg");
I'mage.R'ectWriteFile(image,pRect,"test.jpg");
ImageRectSetColor(image,pRect);
ImageRectMoveKxyAbs(image,pRect,x,y);
ImageRectMoveKxyRel(image,pRect,delta_x,delta_y);
In this case ImageRect is an abstraction that may be used in a lot of functions but is not (and perhaps will never be) an object of its own. LanguageOrientedProgramming requires that such potential for introducing order and symmetry in an API is used.



See also: LanguageOrientedProgramming, ThelopLanguage?


CategoryThelop?


A VirtualObject? is an object that doesn't formally exist within the framework of the programming language. It exists as word, concept and object in the framework of the LopLanguage?. -- HelmutLeitner

These examples are trivial. They are not meant to teach something new. They are necessary to explain the term VirtualObject? as it is used in LanguageOrientedProgramming.


The following function calls are without an explicit object reference. The words "World" and "System" represent the VirtualObject?s (no need to explain them). wtime=WorldRetTime() wtime=World.retTime()

stime=SystemRetTime() stime=System.retTime() Usually programmers would use terms like "namespace" or "toolkit class" to speak about such a situation. But note that in LanguageOrientedProgramming the words "World" and "System" are not arbitrary, they are meant to model real objects. They have to be justified, defined and documented before you are allowed to use them.


The following function calls use more than one parameter as an object reference.

Rewritten (and extended) from the standard C library: MemClear(p,size) MemSetChr(p,size,char) MemCmpStr(p,size,s) StrCpyMem(s,p,size) FileCpyMem(filename,p,size) MemFindStr(p,size,s) MemFindChr(p,size,char) The object Mem is represented by a Pointer and Size parameter (and means an arbitrary range of RAM memory). It stands for an object abstraction that does only exist in the mind of the programmer.

Why not actually represent Mem as a object (strictly an ADT) that holds the pointer and size as member variables, and controls access to those variables with methods or access functions? * Answer one: usually this abstraction is only valid for a very short time, say one or two function calls. So the overhead of an object doesn't make sense. * Answer two: very often it *is* made an object, but then it aquires a meaning, additional functionality and a name. So it is not the virtual object Mem anymore.

Just an example from a "higher level": ImageRectClear(image,pRect); I'mage.R'ectClear(image,pRect); ImageRectWriteFile(image,pRect,"test.jpg"); I'mage.R'ectWriteFile(image,pRect,"test.jpg"); ImageRectSetColor(image,pRect); ImageRectMoveKxyAbs(image,pRect,x,y); ImageRectMoveKxyRel(image,pRect,delta_x,delta_y); In this case ImageRect is an abstraction that may be used in a lot of functions but is not (and perhaps will never be) an object of its own. LanguageOrientedProgramming requires that such potential for introducing order and symmetry in an API is used.


See also: LanguageOrientedProgramming, ThelopLanguage?
CategoryThelop?
 
© ThelopWiki Community zuletzt geändert am September 22, 2003