|
PWCT Features – Programming Paradigm
PWCT don’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 take in mind complex data structures, event-driven systems & network programming.
Imperative 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
Procedural Programming
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 :-
(1) Get Name: Ask the user to enter the name and return this name. (2) DisplayOutput: Get the name as parameter then print the hello message.
Fig. 3 Steps Tree
Object Oriented Programming
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. Class : InputOutput Data : cInputString, cOutputString & cData Methods : GetInput & DisplayOutput
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
Event Driven Programming
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
DoubleS (Super Server) Programming
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)
The first unit is the Code Unit which is based on Circuits/Branches/Switches/Resistances.
To understand the code unit, I expected that you 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.
The another way is to 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 resistances at any time and the resistance code will be executed even if the branch switch is OFF.
Fig. 12 Code Unit
Fig. 13 Resistance
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 Sub Shell 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 Sub Shells from the data unit, you can create a virtual data file, where the first Sub Shell will contains the file structure, and the second Sub Shell will contains the file data.
Fig. 14 Data Unit
Fig. 15 Virtual Data Files
Using a Branch from the Code Unit and a Sub Shell from the Data unit we can create a Class. This class will be dynamic, the class attributes will be the Sub Shell 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
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 Sub Shell in the data unit. This Sub Shell could contain the data that will be received or sent from the server during the communication process.
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.
Look at the next example
We have very simple server called PCounterServer.
This program is a simple client-server application.
The client gets input from the camera; count peoples in a location then send 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 (1) myatom:K:P (2) myatom:K:D We have two channels (1) inchannel points to myatom:K:P (2) outchannel2 points to myatom:K:D
The server can accept four vetoes (messages). (1) Accept Connection (2) Display Data (3) Save File (4) Save Images These messages could be sent from the client to the server.
Each veto point to a resistance in the Code Unit, while each goal in the goal unit override 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 Sub Shell, Here we deal with the Sub Shell electrons using the Channel.
Fig. 19 Steps Tree
Fig. 20 Application During the runtime
Fig. 21 Application during the runtime
More
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 don’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.
|
