ASUNTOS JURÍDICOS, SOBERANÍA Y TERRITORIO

Having established the project methodology, the design patterns involved in De- sireData will now be presented. The main objective is to adopt techniques that would optimize the development process. This includes being able to efficiently achieve the goals set by the project, and to minimize efforts in long term main- tenance. Most of these principles aim to bring together a better organization of code, by reducing its size and to modularize the existing program into distinct

components. In short, these principles will hopefully provide an effective and long lasting foundation for the project.

Avoid code duplication

This notion is critical to improve productivity and efficiency in developing De- sireData. The aim is to examining the overall characteristics of the program and merge similar tasks into generic parts. As a result, the program will eventually be highly modularized. This not only unifies the source code into distinctive components, but also reduces its size by a significant amount. Furthermore, this will benefit the readability of the source files, thus making them more accessible and easily maintained. This concept is often described by using the term OnceAndOnlyOnce (OAOO), originated from the Small talk and Extreme- Programming communities. DRY(DontRepeatYourself) is another terminology used in the Ruby and Pragmatic Programmers communities to categorize this approach. The advantages of code reduction can be summarized in the following two points

• Merges bugs together so that there are less of them to fix. The best debugging technique is to write less code.

• Merges features together so that there are less of them to update. By centralizing behaviors relative to families of features, new features may be implemented easily. Think of coding a new feature that has to interact with ten existing features. Now imagine coding a new feature interacting with only one feature which is the common part between the ten features just mentioned.

The merge of two radio-button classes, horizontal and vertical, demonstrates the effectiveness of this principle. The code specific to radio-buttons is measured about 53kB in conventional Pd. In Impd, it was reduced to 9kB. DesireData, on the other hand, only consists of 181 lines of code that are unique to radio- buttons. Tasks such as handling and rendering radio-buttons in the correct orientation are abstracted into generic methods, which are shared with other

graphical elements such as the slider class. Furthermore, any future imple- mentation on orientation sensitive GUI elements can quickly make use of these methods.

Object-Oriented Programming

One effective approach to achieve better organization of code lies in the domain of Object-Oriented Programming(OOP). Because common elements within the programs are abstracted into generic classes with inheritance relationships, this makes the resulting program very modular and reusable. In conventional Pd, OOP is already implemented in the server using C. In order to efficiently de- couple the client from the server, it is obvious that the client would require its own OOP system.

Poe.tcl was consequently created to facilitate Object-Oriented programming in the client. It provides the OOP mechanism written entirely in Tcl, the language of choice in Pd’s graphical user interface. As Tcl is not an Object- Oriented language, an external system was therefore necessary to enable OOP. Although a few other systems aiming to enable OOP in Tcl also exists, none felt suitable for the purpose of DesireData. One of the main reasons was that by designing a customized OOP system, the syntax which will be employed when building the client can be very flexible. This would ultimately enable a smooth migration in the future if the client is to be ported to a different language. Moreover, having poe.tcl also meant that the distribution of the client can be made very easy, without increasing its dependencies on external software packages. This is because not all existing OOP extensions of Tcl are widely accessible. Furthermore, since Tcl can be extended with additional semantics with a remarkably little amount of Tcl code10

, maintaining and distributing such a minimal customized OOP system is highly practical.

Following the conventions in OOP, classes in DesireData client define a set of generic abstract entities. Most of the classes are created according to a hierarchical order, in which the inheritances on methods and variables are based.

To initialize a class, the syntax class new foo {bar1 bar2} is used, where foo is the class name. Foo also declares its super classes to be bar1 and bar2. Note that multiple superclasses are permitted. The class new method further defines CLASSNAME new as and CLASSNAME new procedures to allow instances of a class to be constructed using a specific ID or a generated one. Once a class is created, the syntax of def CLASSNAME {arglist} {body of method} can then be used to define class method.

Once objects are instantiated, the syntax used to call their methods and send messages to objects is similar to most other OOP systems. The convention is often described as the subject-verb-complements syntax, or also known as receiver-selector-arguments syntax. The first part refers to the unique name or ID of the object, and the second is the name of the method to be called. Any additional elements after the first two are treated as arguments to the method. For example, canvas editmode= 1 will call the method named editmode= with the argument of 1 on the object called exactly canvas.

The underlying mechanisms in poe.tcl to enable method definition and calling is achieved by the combination of proc def {class selector arglist body} and proc lookup method. For instance, by first calling def objectbox draw will actually define a proc named objectbox draw. Then, proc lookup method will reconstruct the appropriate proc name from any receiver-selector-arguments calls and invoke the corresponding proc. To give a realistic example, the message “825ea50 init 450 500 +0+0 1” will initializes object 825ea50 with the arguments 450 500 +0+0 1 and the method called is canvas init with 825ea50 inserted at the beginning of the argument list. In this case, 825ea50 is the ID of an object of class canvas or any subclass of it which does not redefine init.

In poe.tcl, the “@” sign is the prefix which denotes instance variables. This notation is a significant improvement from Impd, in which uses variable con- ventions of Tcl. Instead of typing ($self:x), all its needed now is @x instead. Furthermore, this enables trivial modifications on the existing code to take ad- vantage of the new dict feature in Tcl 8.5.

Model-View Separation

In existing Pd, because graphical rendering is mostly handled in the server, there is essentially no difference between an object and its visual representation. The Model-View design, therefore, aims to further abstract all GUI objects into two parts. It consists of a generic element (Model) that stores the current state of a object, and a rendering part (View) that is in charge of computing the graphics of an object. This separation is necessary to achieve the client and server architecture. By having the View implemented in the client, the server no longer requires to take care of the patch visualization. Furthermore, as long as the means of synchronization is available between the Model and the the View, the client can be used to control the server remotely. Another advantage of this design is that the graphical representation of objects may be easily changed, it is also conceivable to allow multiple Views to be connected to the same Model.

The Model-View implementation is similar to the well known Model-View- Controller design in software engineering. In DesireData, the Controller and the View are the same entity. This is due to the fact that there isn’t a need to implement them individually in the present context. Additionally, the Model exists in both the server and the client. This minimizes the potential traffic in communication by caching the Model’s data in the client.

Observer-Observable

An Observer-Observable pattern is used to handle the communication between the Model and the View in DesireData. Each object is observable, and can be subscribed to an owner. The owner is thus capable of noticing any changes requiring updates within all the objects it observes. For example, a text object is subscribed to the canvas it belongs to, and its changes will then be noticed by the canvas. Through this relationship, all notices are propagated towards the root of the hierarchy and managed centrally. This enables updates to be prioritized by removing any duplications and delaying frequent changes. In fact, there are two Observer-Observable trees per patcher window in Desiredata. One organizes the models and sends updates to the views on the client, the other

manages the views’ update to the Tk canvas. Naturally, the first tree resides in the server, and the second exists in the client. The scheduling of these two update trees are governed by using t clock in the server and the after command in the client. Both mechanisms are functionally equivalent - the former being a feature of Pd and the latter is a Tcl command.