Start Back Next End
  
ZBasic Language Reference
103
ZBasic Microcontrollers
Chapter 4 - ZBasic Object-Oriented Extensions
The purpose of the object-oriented extensions for ZBasic is to bring the benefits of object-oriented
programming - inheritance, polymorphism, and encapsulation - to ZBasic users.  Although ZBasic
historically has been derived from Microsoft Visual Basic (VB6), the decision was made not to implement
the VB object-oriented features in ZBasic largely due to its weak implementation of the inheritance model. 
Since inheritance is one of the primary benefits of object oriented programming, implementing a weak
version of it would do a great disservice to ZBasic users, especially those who are getting their first
exposure to object-oriented programming.  Instead, the realization of ZBasic object-oriented features
takes ideas from other, more popular, object-oriented languages (e.g. C++ and Java) and implements
them in ways that fit well in the ZBasic language structure.
The purpose of this chapter is to briefly describe the important aspects of the ZBasic object-oriented
extensions.  The intended audience is those who have a basic understanding of object-oriented
programming principles.  Those who do not meet this qualification should utilize the many print and
Internet-based resources on the topic before continuing.
4.1 Enabling Object-Oriented Extensions
In order to use the ZBasic object-oriented extensions, you must enable them. This strategy was chosen
so that the additional keywords needed by the extensions do not cause existing programs to fail to
compile.  Enabling the extensions can be achieved by using the directive Option Objects in the first
module compiled.  Alternately, the compiler option –-objects has the same effect; it must occur on the
command line or in the .pjt file before the first .bas file processed.  One side effect of enabling object
extensions is that it also allows overloaded subroutines and functions to be defined outside of a class. 
See section 3.19 for more information on procedure overloading.
4.2 Defining a Class
The characteristics of an object are described by defining a Class.  In many ways, defining a class is
very similar to defining a structure in ZBasic.  However, instead only of having members that are data
items, a class generally will also have members that are subroutines or functions.  As with a structure, the
members of a class may have either Public or Private visibility attributes.  A third visibility attribute,
Protected, affords an additional dimension of access control (described later) that is useful when one
class inherits characteristics from another class.
Similar to defining a Structure, a Class is defined using the ClassEnd Class sequence.  You
may define as many classes in a module as you wish.  A private class cannot be used by code in other
modules while a public class can be.
[Public | Private] Class <name>
<member-definition>
...
End Class
The ellipsis in the syntax above connotes that there may be zero or more additional member definitions. 
As with structures, if neither Public nor Private is specified, the class will be public, meaning that it
will be visible outside of the module in which it is defined.  After a class is defined, its name may be used
as the type in a variable definition.  Consider this simple example.
Public Class myClass
Dim i as Integer
Dim s as String
End Class
A <member-definition> that describes a data member has the same syntax as that used to define a
variable.  As with an ordinary variable, a member may be a single data element or it may be an array. 
Previous page Top Next page