Scripting with Objects

A Comparative Presentation of Object-Oriented Scripting with Perl and Python

Avinash C. Kak

• Publisher: Wiley
• Year: 2017
• ISBN:
  9781119461142
• Edition: 1
• Topic: Informatique
• Subtopic: Programmation en C

Object-Oriented scripting with Perl and Python

Scripting languages are becoming increasingly important for software development. These higher-level languages, with their built-in easy-to-use data structures are convenient for programmers to use as "glue" languages for assembling multi-language applications and for quick prototyping of software architectures. Scripting languages are also used extensively in Web-based applications. Based on the same overall philosophy that made Programming with Objects such a wide success, Scripting with Objects takes a novel dual-language approach to learning advanced scripting with Perl and Python, the dominant languages of the genre. This method of comparing basic syntax and writing application-level scripts is designed to give readers a more comprehensive and expansive perspective on the subject.

Beginning with an overview of the importance of scripting languages—and how they differ from mainstream systems programming languages—the book explores:

• Regular expressions for string processing
  
  

• The notion of a class in Perl and Python
  
  

• Inheritance and polymorphism in Perl and Python
  
  

• Handling exceptions
  
  

• Abstract classes and methods in Perl and Python
  
  

• Weak references for memory management
  
  

• Scripting for graphical user interfaces
  
  

• Multithreaded scripting
  
  

• Scripting for network programming
  
  

• Interacting with databases
  
  

• Processing XML with Perl and Python
  
  

This book serves as an excellent textbook for a one-semester undergraduate course on advanced scripting in which the students have some prior experience using Perl and Python, or for a two-semester course for students who will be experiencing scripting for the first time. Scripting with Objects is also an ideal resource for industry professionals who are making the transition from Perl to Python, or vice versa.

1
Multilanguage View of Application Development and OO Scripting

We now live in a world of multilanguage computing in which two or more languages may be used simultaneously in an application development effort.

Increasingly, application development efforts are thought of as exercises in high-level integration over components that may be independent. Often each component is programmed using a systems programming language and these components are integrated using a scripting language. Although systems programming languages like C and C++ provide type safety,¹ speed, access to existing libraries, fast bittwiddling capabilities, and so on, scripting languages such as Perl and Python allow for rapid application-level prototyping, easier task-level reconfigurability, automatic report generation, easy-to-use interfaces to built-in high-level data structures such as lists, arrays, and hashes for analysis and documentation of task-level performance, and so forth.

What is important is that at both ends — the component end and the integration end — more and more software development is being carried out using object-oriented concepts. The reasons for this are not surprising. The software needs that are driving the object-oriented (OO) movement in the systems programming languages are the same as the needs for scripting languages: code extensibility, code reusability, code modularization, easier maintenance of the code, and so forth. As software becomes increasingly complex, whether for the programming of the individual components or for systems integration, it cries out for solutions that in many cases are provided by OO.

In other words, the fundamental notions of OO — encapsulation, inheritance, and polymorphism, exception handling, and so on — are just as useful for scripting languages as they are for systems programming languages. Since much of the evolution of OO programming took place in the realm of systems programming languages, the aforementioned fundamental concepts of OO are widely associated with those languages. This association is reinforced by the existence of hundreds of books that deal with OO for systems programming languages. Less well known is the fact that, in recent years, OO has become equally central to scripting languages.

You can, of course, get considerable mileage from scripting languages without resorting to the OO style of programming.² The large number of non-OO-based Perl and Python scripts available freely on the internet bears a testimony to that. But the fact remains that much of today’s commercial-grade software in both of these languages is based on OO. Additionally, in Python, even if one does not directly use the concepts of subclassing, inheritance, and polymorphism in a script, the language uses the OO style of function calls for practically everything. That is, you invoke functions on objects, even when the objects are not instances constructed from a class, as opposed to calling functions with object arguments.³ In Perl also, even when you choose not to use the concepts of subclassing, inheritance, and polymorphism, you may nonetheless run headlong into OO when you make use of language features such as tying a variable to a disk-based database file. The simple act of assigning a value to such a variable can alter the database file in any desired manner, including automatically storing the value of the variable on the disk.

Scripting languages did not start out with object-oriented features. Originally, their main purpose was to serve as tools for automating repetitive tasks in system administration. You would, for example, write a small shell script for rotating the log files in a system; this script would run automatically and periodically at certain times (under cron in Unix environments). But over the years, as the languages evolved to incorporate easy-to-use facilities for graphical user interface (GUI) programming, network programming, interfacing with database managers, and so on, the language developers resorted to object orientation.

1.1 SCRIPTING LANGUAGES VERSUS SYSTEMS PROGRAMMING LANGUAGES

Many people today would disagree with the dichotomy suggested by the title of this section, especially if we are to place Perl and Python in the category of scripting languages.

Scripting languages were once purely interpreted. When purely interpreted, code is not converted into a machine-dependent binary executable file in one fell swoop. Instead, each statement, consisting of calls either to other programs or to functions provided specially by the interpreter, is first interpreted and then executed one at a time. An important part of interpretation is the determination of the storage locations of the identifiers in the statements. This determination is generally carried out afresh for each separate statement, commonly causing the interpreted code to run slower than the compiled code. Languages that are purely interpreted usually do not contain facilities for constructing arbitrarily complex data structures.

Yes, Perl and Python are not purely interpreted languages in the sense that is described above. Over the years, both have become large full-blown languages, with practically all the features that one finds in systems programming languages. Additionally, both have a compilation stage, meaning that a script is first compiled and then executed.⁴ The compilation stage checks each statement for syntax accuracy and outputs first an abstract syntax tree representation of the script and then, from that, a bytecode file that is platform independent.⁵ The bytecode is subsequently interpreted by a virtual machine. If necessary, it is possible to compile a Perl or Python script directly into a machine-dependent binary executable file — just as one would do with a C program — and then run the executable file separately, again just as you would execute an a. out or a. exe file for C. The main advantage of first converting a script into an abstract syntax tree and then interpreting the bytecode is that it allows for the intermixing of the compilation and interpretation stages. That is, inside a script you can have a string that is actually another script. When this string is passed as an argument to an evaluation function, the function compiles and executes the argument at run time. Such evaluation functions are frequently called eval.

Therefore, we obviously cannot say that Perl and Python are interpreted languages in the old sense of what used to be meant by “interpreted languages.” Despite that, we obviously cannot lump languages like C and C++ in the same category as languages like Perl and Python. What we have now is an interpreted-to-compiled continuum in which languages like the various Unix shells, AppleScript, MSDOS batch files, and so on, belong at the purely interpreted end and languages like C and C++ belong at the purely compiled end. Other languages like Perl, Python, Lisp, Java, and so on occupy various positions in this continuum.

While compilation versus interpretation may not be a sound criterion to set Perl and Python apart from the systems programming languages like C and C++, there are other criteria that are more telling. We will present these in the rest of this section. The material that follows in this section draws heavily from (and sometimes quotes verbatim from) an article by Ousterhout, creator of the Tcl scripting language [51].

• Closeness to the machine: To achieve the highest possible efficiencies in data access, data manipulation, and the algorithms used for searching, sorting, decision making, and so on, a systems programming language usually sits closer to the machine than a scripting language.
• Purpose: Starting from the most primitive computer element — a word of memory — a systems programming language lets you build custom data structures from scratch and then lets you create computationally efficient implementations for algorithms that require fast numerical or combinatorial manipulation of the data elements. On the other hand, a scripting language is designed for gluing together more task-focused components that may be written using systems programming languages. Additionally, the components utilized in the same script may not all be written using the same systems programming language. So an important attribute of a scripting language is the ease with which it allows interconnections between the components written in other languages — often systems programming languages.
• Strongness of data typing: Fundamentally speaking, the notion of a data type is not inherent to a computer. Any word of memory can hold any type of data, such as an integer, a floating-point value, a memory address, or even an instruction. Nevertheless, systems programming languages are strongly typed in general. When you declare the type of a variable in the source code, you are telling the compiler that the variable will have certain storage and run-time properties. The compiler uses this information to detect errors in the source code and to generate a more computationally efficient executable than would otherwise be the case. As an example of compile-time error checking on the basis of types, the compiler would complain if in C you declare a certain variable to be an integer and then proceed to use it as a pointer. Similarly, if you declare a certain variable to be of type double in Java and then pass it as an argument to a function for a parameter of type int, the compiler would again complain because of possible loss of precision. Using type declarations to catch errors at compile time results in a more dependable product as such errors are caught before the product is shipped out the door. On the other hand, a run-time error would only invite the wrath of the user of the product.
• Regarding binary code optimization, which the compiler can carry out using the type information for systems programming languages, if the compiler knows, for example, that the arguments to a multiplication operator are integers, it can translate that part of the source code into a stream of highly efficient assembly code instructions for integer multiplication. On the other hand, if no such assumption can be made at compile time, the compiler would either defer such data type checking until run time, which would extract some performance penalty at run time, or the compiler would make a default assumption about the data type and simply invoke a more general (albeit less efficient) code for carrying out the operation.
• Data typing is much less important for scripting languages. To permit easy interfacing between the components that are glued together in a script, a scripting language must be as typeless as possible. When the outputs and the inputs of a pair of components are strongly typed, their interconnection may require some special code if there exist type incompatibilities between the outputs of one and the inputs to the other. Or it may become necessary to eliminate the incompatibilities by altering the input/output data types of the components; this would call for changing the source code and recompilation, something that is not always feasible with commercially purchased libraries in binary form. However, in a typeless environment, the output of one component can be taken as a generic stream of bytes and accepted by the rece...