Hi,
I would like to take advantage of the PB OOP structure with an adequate documentation of the program. One of the commonly used documentation of the objects is the UML type with the three basic elements NAME, ATTRIBUTES and ACTIONS. Below I tried to do a projection of this documentation type to the syntax and structure of PB objects/classes. This might illuminate the relation between the objects of the real world with the classes in PB OOP.
####################### OBJECT and Class Definition #############################################
++ Object (UML like structure) ++| +++++++++ CLASS (PB – structure and syntax) ++++++++++++++++++
|
===========NAME=============== | ==CLASS name [$GUID] [AS COM | AS EVENT]========================================================================
| Class Method code blocks...
| [CLASS|OVERRIDE] METHOD name_class_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| METHOD = expression
| END METHOD'
|
========ATTRIBUTES============ | ======INSTANCE attribute AS type ===============================================================================
- - action on generation - -| CLASS METHOD CREATE()
| statements...
| METHOD = expression
| END METHOD
|
- - action on destruction - | CLASS METHOD Destroy()
| statements...
| METHOD = expression
| END METHOD
| |
-----------interface-----------| INTERFACE interfacename [$GUID] [AS EVENT] [AS HIDDEN]
- - - -inheritance- - - -| INHERIT IUNKNOWN
| INHERIT IAUTOMATION
OR | INHERIT IDISPATCH ' only one INHERITANCE per CLASS
|
- - - - new - - - - |
===========ACTIONS============ | ========methods=================================================================================================
|
- - - common action - - - | [CLASS|OVERRIDE] METHOD name_interface_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| METHOD = expression
| END METHOD
| [OVERRIDE] PROPERTY GET|SET name_interface_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| PROPERTY = expression
| END PROPERTY
|
|
----------#######----------- | END INTERFACE
| END CLASS
The projection of OBJECT-NAME and CLASS-NAME, ATTRIBUTES and INSTANCES, and ACTIONS and METHODS are obvious. However, I found in the handbook indication that PB differentiates between METHODS on the class_LEVEL (syntactic position above the INSTANCE definition) and METHODS on the interface_LEVEL. The later are used in combination with the INTERFACE and can be accessed from the outside of the CLASS. The variables (ATTRIBUTES) used in the interface_LEVEL METHODS are defined as INSTANCES.
QUESTION: How are the variables defined/declared for the class_LEVEL METHODS located above the INSTANCE block ?
QUESTION: How are the class_LEVEL METHODS accessed/called inside of the CLASS (any examples ?) ?
QUESTION: Are there any relevant limitation of number, size or type of variables transferred through a METHOD command ?
INHERITANCE implies a hierarchical structure from great grand father/mother to great grand son/daughter. The handbook of PB does not mention such limitation.
QUESTION: If no hierarchical structure is required for the PB INHERITANCE, can we combine CLASSES with a circular referencing INHERITANCE ?
QUESTION: What types of errors can occur if an unlimited circular referencing of CLASSES occurs ?
Thank you for suggestions and replies
Andreas
[/LEFT]
I would like to take advantage of the PB OOP structure with an adequate documentation of the program. One of the commonly used documentation of the objects is the UML type with the three basic elements NAME, ATTRIBUTES and ACTIONS. Below I tried to do a projection of this documentation type to the syntax and structure of PB objects/classes. This might illuminate the relation between the objects of the real world with the classes in PB OOP.
####################### OBJECT and Class Definition #############################################
++ Object (UML like structure) ++| +++++++++ CLASS (PB – structure and syntax) ++++++++++++++++++
|
===========NAME=============== | ==CLASS name [$GUID] [AS COM | AS EVENT]========================================================================
| Class Method code blocks...
| [CLASS|OVERRIDE] METHOD name_class_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| METHOD = expression
| END METHOD'
|
========ATTRIBUTES============ | ======INSTANCE attribute AS type ===============================================================================
- - action on generation - -| CLASS METHOD CREATE()
| statements...
| METHOD = expression
| END METHOD
|
- - action on destruction - | CLASS METHOD Destroy()
| statements...
| METHOD = expression
| END METHOD
| |
-----------interface-----------| INTERFACE interfacename [$GUID] [AS EVENT] [AS HIDDEN]
- - - -inheritance- - - -| INHERIT IUNKNOWN
| INHERIT IAUTOMATION
OR | INHERIT IDISPATCH ' only one INHERITANCE per CLASS
|
- - - - new - - - - |
===========ACTIONS============ | ========methods=================================================================================================
|
- - - common action - - - | [CLASS|OVERRIDE] METHOD name_interface_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| METHOD = expression
| END METHOD
| [OVERRIDE] PROPERTY GET|SET name_interface_level [<DispID>] [ALIAS "altname"] (var AS type...) [AS type]
| statements...
| PROPERTY = expression
| END PROPERTY
|
|
----------#######----------- | END INTERFACE
| END CLASS
The projection of OBJECT-NAME and CLASS-NAME, ATTRIBUTES and INSTANCES, and ACTIONS and METHODS are obvious. However, I found in the handbook indication that PB differentiates between METHODS on the class_LEVEL (syntactic position above the INSTANCE definition) and METHODS on the interface_LEVEL. The later are used in combination with the INTERFACE and can be accessed from the outside of the CLASS. The variables (ATTRIBUTES) used in the interface_LEVEL METHODS are defined as INSTANCES.
QUESTION: How are the variables defined/declared for the class_LEVEL METHODS located above the INSTANCE block ?
QUESTION: How are the class_LEVEL METHODS accessed/called inside of the CLASS (any examples ?) ?
QUESTION: Are there any relevant limitation of number, size or type of variables transferred through a METHOD command ?
INHERITANCE implies a hierarchical structure from great grand father/mother to great grand son/daughter. The handbook of PB does not mention such limitation.
QUESTION: If no hierarchical structure is required for the PB INHERITANCE, can we combine CLASSES with a circular referencing INHERITANCE ?
QUESTION: What types of errors can occur if an unlimited circular referencing of CLASSES occurs ?
Thank you for suggestions and replies
Andreas
[/LEFT]
Comment