CARACTERÍSTICAS DE LA CRISIS FINANCIERA DE

There are many programming paradigms; some of them are widespread while others are adopted rarely. Most languages support several paradigms; the sup- port can be either explicit or implicit. Explicit support means that the language constructs are designed with a particular programming paradigm in mind. Im- plicit support only allows a particular paradigm to be used in the language; however, usually with less convenience.

4.4.1

Objects, Aspect, Contracts, ...

It is possible to write an object oriented program in plain C but it generally re- quires more effort than implementing the same program in C++ or Objective-C.

Design by Contract (DbC) is explicitly supported in Eiffel and D programming

language (note that none of these languages are mainstream); however, this paradigm can be easily embraced by many languages. Se also section 3.2.3 for more information about DbC.

Some paradigms, such as Aspect Oriented Programming (AOP, see section 3.3.4), cannot be easily embraced in a programming language that does not have explicit support for it.

The key process of AOP is called aspect weaving. If the language has an explicit support for AOP, the aspect weaver is a part of the compiler or inter- preter. One can also create aspect weaver as an external tool that works as a source code preprocessor or byte-code postprocessor.

There is a better implicit support for new paradigms in dynamic languages than in static languages. The reason is that the structure of the program, the program’s object space, can be manipulated at run-time. This manipulation is done within the program itself. Utilization of self-modifying constructs in a dynamic language is much easier than customization of a compiler of a static language or a virtual machine.

In order to demonstrate this fact, we have implemented a simple DbC sup- port in Python, see figure 4.4. Our implementation assumes that for a par- ticular method, there may exist an auxiliary method that checks precondi- tion: the method factorial has an auxiliary precondition check in method fac-

torial__precond. The DbC weaver transforms a class, in our example the Math

class. The transformation injects call of the precondition check method before every call of the method that actually implements the desired functionality, i.e., the factorial__precond method is always called before the factorial method. Postcondition checks can be implemented in the same way.

1 d e f make_wrapped_call ( func , precond ) :

2 d e f wrapped (∗ a r g s ) :

3 # This wrapper f i r s t c a l l s the p r e c o n d i t i o n check ,

4 # then the o r i g i n a l method .

5 precond (∗ a r g s ) 6 r e t u r n func (∗ a r g s ) 7 r e t u r n wrapped 8 9 c l a s s DbcWeaver ( type ) : 10 d e f __init__ ( c l s , clsname , bases , d i c t ) :

11 super ( DbcWeaver , c l s ) . __init__ ( clsname , bases , d i c t )

12 13 f o r name i n d i c t . keys ( ) :

14 # This method w i l l be wrapped .

15 func = d i c t [ name ] 16 i f not c a l l a b l e ( func ) : c o n t i n u e 17 18 t r y : 19 # Try to o b t a i n the method tha t w i l l be used f o r

20 # p r e c o n d i t i o n c h e c k i n g .

21 # I t i s i d e n t i f i e d by naming co nventio n .

22 precond = d i c t [ name + ’ __precond ’ ]

23 except KeyError :

24 # There i s not a p r e c o n d i t i o n

25 # check f o r method " func " .

26 c o n t i n u e

27 28 # Set wrapped method i n s t e a d o f the o r i g i n a l one .

29 s e t a t t r ( c l s , name , make_wrapped_call ( func , precond ) )

30 31 c l a s s Math : 32 # Weaving w i l l be a p p l i e d to t h i s c l a s s . 33 __metaclass__ = DbcWeaver 34 35 d e f f a c t o r i a l _ _ p r e c o n d ( s e l f , n ) : 36 # A f t e r weaving , t h i s method i s c a l l e d 37 # b e f o r e " f a c t o r i a l " method . 38 a s s e r t n >= 0 39 40 d e f f a c t o r i a l ( s e l f , n ) : 41 r e s u l t = 1 42 f o r i i n xrange ( 2 , n +1): 43 r e s u l t ∗= i 44 r e t u r n r e s u l t

Chapter 4. Towards High Level Dynamic Approach

of the Math class.

Note that our example relies on Python’s support for metaprogramming (see the __metaclass__ attribute); however, this support is only a sort of syntactic sugar and an equivalent functionality can be achieved without it. The weaver traverses through all attributes of a newly constructed class and suitable methods are replaced by methods that first do the precondition check and then call the original algorithm implementation.

Our example shows one way how a new paradigm can be incorporated into a dynamic language. We also use slightly different approach to DbC in our FTP client case study, see section 10.2.2.

4.4.2

Domain Specific Languages

Dynamically typed languages also provide viable base for building domain spe- cific languages, because they provide useful features such as named (keyword) arguments, closures and operator overloading (in the case of Ruby). These features enable the classes and objects of some domain-specific library to be accessed in a way natural for the domain.

Good examples are Rake2 _{and SCons}3 _{that are software construction tools} like GNU Make and Apache Ant. Rake is based on Ruby while SCons is Python- based. See simple examples in figures 4.5, 4.6, and 4.7 for illustration of how Ruby and Python can be used to build a makefile-like DSL.

See figure 4.8 for an example of relation data definition and querying in Python, literally Django4 _{web framework. These constructs are used for gener-} ating appropriate SQL commands.