PWCT Features – Programming Paradigm

PWCT doesn’t force a programming paradigm for solving problems.

You can use different programming paradigms like imperative, procedural, object-oriented, functional, event-driven, data driven, etc.

The support of a programming paradigm is based on the textual programming language behind the visual programming language, if the textual programming language support a programming paradigm then you can use it through PWCT but instead of typing the text based source code you will use visual programming.

For the HarbourPWCT visual programming language, PWCT comes with a new programming paradigm called DoubleS (Super Server Programming Paradigm). This programming paradigm takes in mind complex data structures, event-driven systems & network programming.

The next program asks the user to enter his/her name then print hello message to the user using his/her name. The program steps are executed sequentially (Step by Step) — “Do this then do that.”

Fig. 1 Steps Tree

Fig. 2 Application during the runtime

Here we have the same program which asks the user to enter his/her name then print hello message to the user using his/her name, but at this time we have two functions:

Fig. 3 Steps Tree

Here we have the same program which asks the user to enter his/her name then print hello message to the user using his/her name, but we have one class and one object.

Fig. 4 Steps Tree

Fig. 5 Interaction Page

Here we create another sub class called GetAddress from the InputOutput Class.

Fig. 6 Steps Tree

Fig. 7 Interaction Page

In this example we display the current time every second using a timer.

Fig. 8 Steps Tree

Fig. 9 Interaction Page

Fig. 10 Application during the runtime

PWCT comes with a new programming paradigm called DoubleS (Super Server).

The idea behind the super server programming paradigm is to design your software as a group of servers communicating together by message & data passing in a real network environment but each server must be organized as a group of interacting units where these units are based on concepts from Chemistry, Electrical Circuits, Human Interaction & Visual Programming. Also these units can emulate the different programming paradigms like imperative, procedural, event-driven, object-oriented, agent-oriented & language oriented programming.

DoubleS is a paradigm of paradigms, rules to mix things together to solve the problem without breaking the organization of the systems. A paradigm designed for very large programs.

Fig. 11 Server Units (Data, Code, Veto & Goal)

Code Unit

The first unit is the Code Unit which is based on Circuits/Branches/Switches/Resistances.

To understand the code unit, you should already know procedures/functions/methods. The resistance is not more than a procedure, function or method.

The branch is a group of resistances where these resistances will run in a specific order (up/down or down/up) if the branch switch is ON.

The circuit is a group of branches where these branches will run in a specific order (Up/Down or Down/Up) if the circuit switch is ON.

The code unit could contain one or more of circuits.

We have two ways to run the Code Unit: we can use the “Server Fire ON” method where the server will start in a loop and will execute the resistances based on the switches status (this loop is infinite), or we can call the Main Resistance (like the main function in the C language).

We can create a resistance as a procedure/function but with long address like CircuitName\BranchName\ResistanceName

Then we can call this resistance at any time and the resistance code will be executed even if the branch switch is OFF.

Fig. 12 Code Unit

Fig. 13 Resistance

Data Unit

The Data Unit is used for managing the system data, starting from things you already know (Variables), (References/Pointers) & (Data/Value) — all of these things are called (Electrons).

The electron could be just Data/Value, Variable or Reference/Pointer.

The SubShell is a group of Electrons, you can think of it as Array, Stack or Queue.

We can copy or move electrons from one SubShell to another one.

The Shell is a group of SubShells. The Atom is a group of Shells. The Vessel is a group of Atoms.

The Reaction is a filter for Vessels and/or Atoms based on Shells or SubShells names.

To use the Data Unit from the Code Unit, you can do (Load/Upload) operations. You can load a SubShell to get the SubShell electrons. If the SubShell contains variables, when you load it, these variables will be defined in the current scope and you can use it directly.

You will have a copy of these electrons (Variables/References/Data), you can do changes without affecting the Data Unit. If you want to update the Data Unit with your changes, you can do Upload.

Using two SubShells from the data unit, you can create a virtual data file, where the first SubShell will contain the file structure, and the second SubShell will contain the file data.

Fig. 14 Data Unit

Fig. 15 Virtual Data Files

OOP Simulation

Using a Branch from the Code Unit and a SubShell from the Data Unit we can create a Class. This class will be dynamic, the class attributes will be the SubShell Electrons, and the class methods will be the Branch resistances.

You can create classes from these dynamic classes (inheritance).

Creating Classes & Objects here is called OOP (Object-Oriented-Programming) Simulation.

Fig. 16 Creating Dynamic Classes

Fig. 17 Object Oriented Simulation

Veto Unit

The veto unit is used for communication between the servers by sending messages and data.

The veto unit contains Connections, Channels & Vetoes. The message is called (Veto). The connection is used to connect between the server and other servers.

The channel is a pointer to a SubShell in the data unit. This SubShell could contain the data that will be received or sent from the server during the communication process.

Goal Unit

The Goal Unit is a group of goals, where each goal could replace a resistance in the Code Unit.

Using the Goal Unit, we can do visual programming instead of typing text based source code.

Example: PCounterServer

We have a very simple server called PCounterServer. This program is a simple client-server application.

The client gets input from the camera, counts people in a location then sends the image and the results to the server. This process is always running, a delay for one second is added to this continuous process.

The Server collects data (images & people count) from different clients.

In this example we have two SubShells:

We have two channels:

The server can accept four vetoes (messages):

These messages could be sent from the client to the server.

Each veto points to a resistance in the Code Unit, while each goal in the Goal Unit overrides one of these resistances to develop the program using visual programming instead of typing the text based code.

Fig. 18 Server Units Window

The next steps tree contains the steps at the server side for getting the image and the information from the client, these data will be in the data unit inside a SubShell. Here we deal with the SubShell electrons using the Channel.

Fig. 19 Steps Tree

Fig. 20 Application During the runtime

Fig. 21 Application during the runtime

In the previous examples we have seen that we can use different programming paradigms. This is because the Harbour programming language is a multi paradigm language, PWCT doesn’t force a programming paradigm and HarbourPWCT covers many of Harbour features.

PWCT comes with a new programming paradigm called DoubleS (Super Server).

Using PythonPWCT you can use the Functional programming paradigm.