PBDJ - PowerBuilder Journal

Nowadays .NET has become a mainstream programming platform. To be inline with PowerBuilder's .NET deployment and .NET development strategy, the PowerScript language will be enhanced to be a true CLS-compliant .NET language in PowerBuilder 12. Users will be able to consume and extend any CLS-compliant .NET resource, thereby saving them a lot of development time.

On the other hand, many modern language features will be brought into PowerScript as well, such as interface and namespace. These features are delivered in a 4GL manner to maintain PB's productivity and bring PowerScript's differentiators to other .NET languages. The original PowerBuilder object model is kept as much as possible to maintain the backward-compatibility; minimize the learning curve; and preserve customers' investment, knowledge, and skills in PowerBuilder.

Figure 1 shows the relationship among CLS and various .NET languages. As we can see, CLS is the core portion of all .NET languages and defines the minimum language requirements that must be supported by any .NET language. Meanwhile each .NET language has its own unique language features as well, for example. Other than standard .NET primitive types, PB also supports its own unique primitive types, such as blob and any.

CLS is a set of rules intended to promote language interoperability. Since PowerScript is a CLS-compliant language, it will be able to consume and extend any CLS-compliant resource produced by other .NET languages and, in the meantime, produce PB .NET assemblies/Web services as a CLS-compliant component for any other .NET language consumption.

Non-CLS-compliant .NET resources are considered to be consumed or extended by PowerBuilder case-by-case. For example, if the resource only involves unsigned integer types that are not CLS-compliant types, PB will be able to support it.

However, a PB .NET target application (Windows Forms, Web Forms, or WPF) will not be limited to only CLS-compliant features. The user is able to make use of any of PowerBuilder's language elements to develop their applications.

In PB12, the type system of PowerScript is strongly enhanced to be in-line with .NET type hierarchies except for .NET boxed value types and pointer types since they are not required for CLS-compliance. PB primitive types are equivalent to their corresponding .NET primitive types, for example, the PB long type is mapped to the .NET System.Int32 type. The .NET Sytem.Enum type is the base type of all PB enumerated types, just like the .NET System.Array type to PB array types. In .NET, the System.Object type is the root type of all .NET types, after enhancing PowerBuilder PowerObject types to inherit from the .NET System.Object type, which will be the root type of all PB types as well.

In the original PowerBuilder, the array-bound information can only be specified at compile time. This limitation prevents users from dynamically creating an array with bound information at runtime, which is a pretty common scenario in .NET programming since the size of an array is usually unknown at compile time.

To overcome this limitation, in PowerBuilder 12 an array type is enhanced to be dynamically created at runtime no matter if it is a single dimensional array, a multi-dimensional array, or a new introduced jagged array as follows:

int ar1[]
ar1 = create int[2]{1,2}
int ar2[,]
ar2 = create int[2, 2 to 5]
int ar3[][]
ar3 = create int[2][]
ar3[1] = create int[5]
ar3[2] = create int[10]A

An array type can also be used as the return type of functions or events:

public function integer[] test_ret_array()

A user-defined enumerated type is introduced in PB12 as well. Users will be able to define global enumerated types in their applications:

global type MyEnum enumerated
item1,
item2 = 3
end type

The items of a user-defined enumerated type are accessed with the following syntax:

[namespaceName].enumeratedType.enumeratedEntryName!

In addition, similar to local structure, a local enumerated type can also be defined in the following kinds of PowerBuilder objects: Custom Class, Standard Class, Custom Visual, Standard Visual, Window, and Menu.

In .NET, an interface defines a contract. A class that implements an interface must adhere to its contract. In PowerBuilder 12, users are allowed to define their own interface types as well, and function, event, property, and indexer elements can be included in an interface type:

global type ISub1 interface[from IBase1, ...]
function string f(int i) //function
int prop[get, set] //property
event type int e() //event
string this[int i, int j][get,set] //indexer
end type

In addition, four system-defined DataWindow interfaces are introduced: IDataWindowBase, IDataWindowChild, IDataWindowControl and IDataStore, which provide the common functionality of an existing DataWindow, DataStore and DataWindowChild objects. IDataWindowBase is the base interface of the other three interfaces. Those four interfaces can be used as the type of any kinds of variables or the parameters of functions or events.

Here is a sample of how to make use of DataWindow system-defined interfaces:

public string function get_name (IDataWindowBase dw)
return dw.GetColumnName()
end function

Currently in PowerBuilder, a default constructor event is used to instantiate an object. When a PB NVO object is created at runtime, an autogenerated oncreate event will be triggered in which the default constructor event is subsequently triggered.

Since the default constructor event cannot be overloaded, the flexibility to instantiate and initialize a particular type of object is lost.

In PowerBuilder 12, parameterized constructor events will be able to be defined in custom and standard NVO types as follows:

global type NVO form NvoVisualObject
event type long constructor(string s1, string s2)
end type

Later, users can create the object with the parameterized constructor events they defined for it before:

nvo1 = create nvo("s1", "s2")

Some rules about the parameterized constructor event in PB are: if the default constructor event is defined in the ancestor object, it is optional to invoke any ancestor's constructor event in a descendant's constructor event. However, if the default constructor event is not defined in an ancestor object, but some parameterized constructor events are defined, then it is mandatory to invoke any ancestor's constructor event in the descendant's constructor event.

And invoking an ancestor's constructor event must be the first statement in the descendant's constructor event:

call super::constructor(p1, p2)

In PowerBuilder 12, the following PB object types can implement user-defined interfaces: Custom Class, Standard Class, Custom Visual, Standard Visual, Window, and Menu as shown in the following example: