domingo, 27 de diciembre de 2009

Call Super en API de Android


Un API o un framework bien diseñado debe acotar al máximo las posibilidades de que sus usuarios hagan macanas. No puedo decir que la plataforma Android esté en general mal diseñada, pero ahí encuentro un antipatrón que presentaré como ejemplo.


Android provee la clase Activity, que uno debe subclasear para definir actividades específicas. La clase define varios métodos que deben ser sobreescritos en la subclase.


En el javadoc del método onCreateOptionsMenu leemos:


The default implementation populates the menu with standard system menu items. These are placed in the CATEGORY_SYSTEM group so that they will be correctly ordered with application-defined menu items. Deriving classes should always call through to the base implementation.


¿Hay algo que les haga ruido en esta descripción? Si no, piénsenlo un poco.


Nos dice que la implementación default llena el menú con... bla bla bla. OK, creo que hasta podemos ignorar lo que hace. Pero dice que las subclases deben siempre llamar a la implementación base. La pregunta del millón: si siempre hay que hacer X cosa, ¿por qué arriesgarnos a que se me ocurra no hacerla, o me olvide? Lo que deba hacerse siempre, no debe requerir mi intervención.


Vean si no, cómo se les escapó la llamada a ellos mismos en un ejemplo.


En el tutorial de la Notepad Application aportan a la confusión con el valor de retorno:


@Overridepublic
boolean onCreateOptionsMenu(Menu menu) {
boolean result = super.onCreateOptionsMenu(menu);
menu.add(0, INSERT_ID, 0, R.string.menu_insert);
return result;
}


El javadoc dice que debemos retornar true si se debe mostrar el menú, false en caso contrario. Entonces, ¿por qué retornar lo que diga la implementación base? He visto otros ejemplos en los que se ignora el retorno de la implementación base, y se retorna true. ¿Será que la implementación base retorna siempre true? Estas dudas molestan, entorpecen. No deberíamos estar en situación de hacernos esas preguntas, la culpa es del mal diseño.


En wikipedia me entero que el antipatrón es conocido como Call Super.


Como allí bien se explica, esto se corrige aplicando el patrón Template Method. Activity podría haber definido el método así:



public final boolean baseOnCreateOptionsMenu(Menu menu) {
// ...
return onCreateOptionsMenu(menu);
}
public boolean onCreateOptionsMenu(Menu menu) {
return true;
}


El método baseOnCreateOptionsMenu() no puede ser sobreescrito porque es final. El framework, ante el evento correspondiente, llamaría a éste método, que contiene "la implementación base", y éste a su vez llama a onCreateOptionsMenu(), que sí podemos sobreescribir libremente.


Así nadie mete la pata, y todos contentos.

miércoles, 2 de septiembre de 2009

Anillo inmutable

Se me presentó un caso para el que necesité un tipo de colección que no está en la librería estándar de Java ni la de Scala: una lista circular. Que se la pueda recorrer en ambos sentidos, que no tenga fin. Seguramente hay implementaciones por ahí pero lo tomé como un ejercicio.

Ya me acostumbré a usar estructuras inmutables por default, así que este anillo será inmutable. Primer paso: definir el API. 
trait Ring[T]
{
  def get: T
  def next: Ring[T]
  def previous: Ring[T]
}
Bien simple. La idea es que una instancia de Ring me da acceso al elemento "actual" únicamente, con el método get. Con next y previous obtengo un nuevo Ring, con el mismo contenido, donde el elemento "actual" es el próximo o el anterior respectivamente.

Cualquier implementación de una colección inmutable debe contemplar alguna manera de establecer el contenido. Una alternativa es proveer el contenido en una colección más "básica" como sería un Array[T], donde los elementos están en un orden determinado. El anillo nos da una vista de ese contenido en la que los extremos están unidos. En este caso, el Array, aparte de ser el proveedor de contenido para el anillo, es la estructura subyacente de la implementación: con next y previous se reinstancia Ring pero siempre compartiendo la misma instancia del Array. El trabajo del anillo es escencialmente mantener un índice al elemento actual. Una implementación que promete eficiencia.
class ArrayRing[T](elems: Array[T], curIndex: Int) extends Ring[T]
{
    def this(elems: Array[T]) = this(elems, 0)
    
    if(elems == null) throw new IllegalArgumentException
    if(curIndex < 0 || curIndex >= elems.size) throw new IndexOutOfBoundsException

    def get: T = elems(curIndex)
    
    def next: Ring[T] = new ArrayRing(elems, if(curIndex < elems.size - 1) curIndex + 1 else 0)
 
    def previous: Ring[T] = new ArrayRing(elems, if(curIndex > 0) curIndex - 1 else elems.size - 1) 
}
Al instanciar ArrayRing, se puede indicar qué índice corresponde al elemento actual; si no, se asume el primero (0).

Me vino bien para lo que necesitaba, pero no incluiría esta clase en una librería para terceros porque cometí un sutil pecado. Si lo presento como un anillo inmutable, y de hecho eso se desprende del API, no puedo usar como estructura subyacente una colección mutable (Array) que está fuera de mi control. La clase se comporta como si el Array nunca cambiara, cuando nada garantiza tal cosa. Desde el punto de vista del usuario de la clase, nada revela que el Array se utiliza para algo más que para proveer los elementos al anillo; uno supondría que, una vez instanciado el ArrayRing, éste pierde toda dependencia con el Array informado.

Entonces, hagan lo que yo digo, no lo que yo hago. Una mejor implementación debería pedir una colección inmutable (y en ese caso no importa si se utiliza como estructura subyacente o no), o bien tomar el Array pero pasar sus elementos a alguna otra estructura interna. En éste último caso sería conveniente reutilizar esa estructura interna al reinstanciar el anillo con next y previous, para no perder en eficiencia.

sábado, 30 de mayo de 2009

El backstage de NS-Matic: índice de posts

Ahora que NS-Matic está online gracias a Google AppEngine, les dejo un índice de los posts que podemos considerar backstage del proyecto: desde el parseo de PL/SQL, pasando por la construcción del AST, hasta la generación de diagramas en diferentes tecnologías.

  1. Parseando en Scala (1): Intro 
  2. Parseando en Scala (2): Metasintaxis y AST 
  3. Parseando en Scala (3): Modelo 
  4. Parseando en Scala (4): Combinator parsing en acción 
  5. Parseando en Scala (5): El código 
  6. Parseando en Scala (6): Generando la salida 
  7. Una vuelta de tuerca más a la generación del diagrama 
  8. Superando el desafío de llevar el generador de diagramas a AppEngine 

Superando el desafío de llevar el generador de diagramas a AppEngine


El parseador y generador de diagramas del que hablábamos por acá ahora tiene nombre y está publicado como aplicación web en Google AppEngine: NS-Matic .
Como se sabe, desde hace poco AppEngine soporta Java, y eso significa que soporta varios lenguajes más: todos aquellos que compilan a bytecode para la JVM. Lo que yo no sabía hasta luego del primer deploy, era que las limitaciones impuestas por Google iban a frustrar el plan. Resulta que hay una lista blanca de clases estándar disponibles, entre las cuales no están las de AWT. En AppEngine no se puede instanciar ninguna clase de AWT. Google provee un API alternativo de manipulación de imágenes pero no incluye el tipo de operaciones que mi aplicación necesitaba.
Al no poder generar imágenes en el servidor, consideré usar el viejo generador de HTML. Pero no me quise conformar, e investigué la posibilidad de pasarle el fardo al cliente: ¿se puede dibujar en el navegador?

Dojo al rescate

No estaba al tanto pero resulta que sí, todo navegador que se precie hoy en día tiene capacidad de gráficos vectoriales. La mayoría con SVG, Internet Explorer con VML (cuándo no, cortándose solo). Cómo será la cosa: se está hablando de que esto le vaya ganando terreno a Flash. Para resolver las diferencias entre navegadores, podemos usar una librería cross-browser como Dojo Toolkit , y su módulo Gfx que sirve precisamente para graficar. En mis diagramas, el resultado se ve mejor que los GIF que generaba antes con AWT. Lo que se pierde es la posibilidad de guardar el diagrama como un archivo de imagen, lo que sería más práctico que guardar una página con javascript.

Antes dijimos que estábamos preparados para agregar nuevas implementaciones de generadores de diagramas porque teníamos un diseño extensible. El generador de AWT recorría el AST y daba como resultado un BufferedImage; el nuevo debería recorrer el AST y retornar un String con el script a ser ejecutado por el navegador.

Pero esto nos lleva a un nuevo replanteo: los generadores de AWT y Dojo Gfx, si bien apuntan a tecnologías diferentes (el cómo), tienen un núcleo común: el qué. Antes estábamos mezclando el qué y el cómo, ahora estamos obligados a extraer el qué, si queremos hacer las cosas bien.

El graficador abstracto

La idea sería poder definir en abstracto qué líneas hay que trazar y qué texto hay que desplegar, y en qué posición. Para esto necesitamos un modelo sencillo para generadores de tipo gráfico, que tengan la capacidad de tomar esa especificación y ejecutarla en alguna tecnología.

trait Alignment
case class AlignLeft() extends Alignment
case class AlignCenter() extends Alignment

case class Pos(x:Int, y:Int) {
  def shift(dx:Int, dy:Int) = Pos(x + dx, y + dy)
}
case class Line(from:Pos, to:Pos)
case class TextLine(text:String, anchor:Pos, align:Alignment)

Pos define una posición (x,y), y con el método shift obtenemos una nueva posición con un delta horizontal y otro vertical. El concepto de posición, y la posibilidad de obtener una a partir de otra preexistente, serán de uso intensivo en esta solución. Line y TextLine definen los dos elementos básicos que sirven para armar todo.

class GraphicElement(
    val pos:Pos, 
    val width:Int, 
    val elemHeight:Int,
    val textLines: List[TextLine],
    val lines: List[Line],
    val children: List[GraphicElement]) 
{
  lazy val height: Int = maxY - minY 
  lazy val nextPos = pos.shift(0, height)
  
  private def minY = children match {
    case Nil => pos.y
    case _ => (children map (_.pos.y)) reduceLeft (_ min _) min pos.y
  } 
    
  private def maxY:Int = children match {
    case Nil => pos.y + elemHeight
    case _ =>   ((children map (_.maxY)) reduceLeft (_ max _)) max (pos.y + elemHeight)
  }
}

GraphicElement define un nodo gráfico como contenedor de objetos Line, TextLine, y nodos hijos del mismo tipo. El resultado del proceso será un árbol de nodos de éste único tipo. Para calcular en qué posición vertical se ubica cada elemento, es necesario establecer claramente cuánto espacio vertical ocupa cada uno. Al instanciar un GraphicElement, en elemHeight indicamos la altura "neta" del elemento, es decir, cuánto ocupa en vertical sin tomar en cuenta los nodos hijos. Podría ser cero en el caso de un simple contenedor de nodos. Lo que no indicamos nosotros es la altura "bruta", que incluye la de los hijos. Esa la calcula el campo height. Con el método nextPos vemos que cualquier elemento puede determinar la posición "siguiente" que se puede usar como origen del elemento que le sigue, cuando hay varios al mismo nivel. Y lo hace en términos de la posición propia, desplazada en vertical la altura propia.

Acá vemos una versión recortada del pre-generador para gráficos. El método generate retorna el GraphicElement raíz del árbol.

class GraphicGenerator(totalWidth: Int) 
{
  // ... codigo omitido 
  
  private def layoutText(s:String, p:Pos, w:Int, 
                         align:Alignment):List[TextLine] = // ...etc

  private def makeChildren(nodes:List[Node], prevElem:GraphicElement, 
                           w:Int):List[GraphicElement] = // ...etc
  
  def generate(n:Node):GraphicElement = generate(n, Pos(0,0), totalWidth)
  
  private def generate(n:Node, p:Pos, w:Int): GraphicElement = n match
  {
    case s:Stmt =>       
      val textLines = layoutText(s.text, p.shift(5, STMT_HEIGHT - 5), w, AlignLeft())
      val height = (STMT_HEIGHT - TEXT_HEIGHT) + (TEXT_HEIGHT * textLines.size)
      new GraphicElement(p, w, height, textLines, Nil, Nil)
    case f:Loop =>
      val blockWidth = w - STMT_HEIGHT
      val textLines = layoutText(f.text, p.shift(5, STMT_HEIGHT - 5), w, AlignLeft())
      val height = (STMT_HEIGHT - TEXT_HEIGHT) + (TEXT_HEIGHT * textLines.size)
      val blockPos = p.shift(STMT_HEIGHT, height)
      val children = makeChildren(f.body, GraphicElement.nullObject(blockPos), blockWidth)
      val childrenHeight = GraphicElement.sumHeights(children)
      val blockLines = List(Line(p.shift(0,childrenHeight+height), p.shift(w, childrenHeight+height)),
                            Line(p, p.shift(w,0)),
                            Line(blockPos, blockPos.shift(blockWidth,0)),
                            Line(blockPos, blockPos.shift(0,GraphicElement.sumHeights(children))))
      new GraphicElement(p, w, height, textLines, blockLines, children)

    // ... y el resto de los nodos del AST
  }
}

Como ejemplo vemos la resolución de los nodos Stmt (statement) y Loop. No importan mucho los detalles, pero señalaremos un par de cosas. Usamos el método layoutText cada vez que tenemos que generar texto; no podemos directamente instanciar un TextLine a partir de un String porque puede ocurrir que no nos dé el ancho disponible y haya que wrapear ese String. El método resuelve el wrapping y devuelve una lista de TextLine.
El método makeChildren procesa una lista de Node, invocando generate por cada uno, y determinando la posición de cada uno con nextPos del elemento anterior. Le pasamos como argumento un GraphicElement.nullObject, que es un GraphicElement vacío que sirve sólo para definir la posición inicial de esa secuencia de nodos.

Una vez que nos sacamos de encima todo el trabajo pesado, definamos un marco para las implementaciones gráficas. Estas ya no necesitan conocer el modelo del AST (Node y sus subtipos: Stmt, Loop, etc.) porque sólo trabajarán en términos de objetos GraphicElement.

abstract class GraphicBasedGenerator[T](width:Int) {
  def generate(n:Node):T = {
    val s = new GraphicGenerator(width).generate(n)
    generate(s)
  }
  def generate(ge:GraphicElement):T
}

Esta clase ya resuelve el uso del graficador abstracto que a partir de un Node raíz obtiene un GraphicElement raíz. Queda por definir la generación de un T (tipo que depende del renderizado a usar) a partir de un GraphicElement. Entonces, implementé un graficador para Dojo Gfx como subclase de GraphicBasedGenerator, que es bastante sencillo y no incluyo en el post para no alargarlo más.

jueves, 14 de mayo de 2009

El problema del cuadrado con numeritos

Me topé con un problema irresistible, descripto en inglés en este post. No me haría ninguna gracia tener que resolverlo en una entrevista de trabajo, como fue el caso de aquel blogger: mi primer intento, en la tranquilidad de mi casa, fue lento y torpe. Pero es de esos problemas que, una vez leido el enunciado, no se pueden ignorar: si sos programador y mínimamente te gusta tu profesión, deberás resolverlo. Sugiero que lo lean allá, sin ver soluciones, y... ya sabrán que hacer.

Spoiler Alert

La solución en C del blogger me pareció inteserante por lo concisa, lo mismo la de algunos comentaristas de ese blog, que utilizaron diferentes lenguajes. Cuándo no, la mía es en Scala. Con Scala se puede apuntar a una solución concisa por su poder expresivo, pero no quise descuidar otro aspecto: que el código capture la intención. Es una solución funcional, y con objetos (uso un par de clases). Este es el resultado:

case class Pos(i:Int, j:Int)
{
  def shiftIn = Pos(i - 1, j - 1)
}

case class Square(n:Int)
{
  val highest = (n * n) - 1
  val farEdge = n - 1
  private def isEdge(x:Int) = x == 0 || x == farEdge
  private def isEdge(p:Pos):Boolean = isEdge(p.i) || isEdge(p.j)
  private def isTopOrRight(p:Pos) = p.i == 0 || p.j == farEdge
  private def linearOffset(p:Pos) = if(isTopOrRight(p)) p.j + p.i else (farEdge * 2) + (farEdge - p.j) + (farEdge - p.i)
  private def calc(p:Pos):Int = if(isEdge(p)) highest - linearOffset(p) else Square(n - 2).calc(p.shiftIn)

  def calc(i:Int, j:Int):Int = calc(Pos(i,j))
}


Square es un cuadrado de n celdas de lado. Pos es una posición (i, j). Definimos valores para ayudar en la claridad del código: highest es el valor más alto del cuadrado (que estaría en la celda superior izquierda). farEdge es el índice al "borde lejano"... o sea, el borde horizontal cercano es la fila 0, y el lejano la fila farEdge; igual con los bordes verticales (columnas 0 y farEdge).
Los métodos privados conceptualizan los detalles de la implementación. El método calc, en palabras se describiría así:

Si la posición solicitada corresponde a un borde del cuadrado, tomar el valor más alto del cuadrado y restarle un offset lineal deesa posición respecto al contorno del cuadrado.
Si no, intentar con el cuadrado interno al actual.

El método isEdge nos dice si la posición indicada cae en un borde del cuadrado, es decir, que la fila o la columna sea 0 o sea farEdge.
Lo del offset lineal surge de observar, en el planteo del problema, una característica de todos los "anillos" cuadrados que forman la grilla, desde el borde exterior hasta la celda central (o cuadrado de 2 x 2): Desde la celda superior izquierda, que contiene el máximo valor del cuadrado, podemos recorrer el borde en sentido reloj, y son todos valores decrecientes de uno en uno. Si "enderezamos" ese borde, tenemos un vector donde la primera posición es la más alta. Pero como su contenido es tan obvio, no necesitamos representarlo en memoria. Dado un índice, podemos calcular fácilmente el valor que habría en tal posición: en la 0 está highest, en la 1 está highest - 1, y así. Entonces, la única dificultad es obtener ese offset lineal, el índice al vector imaginario, a partir de una posición bidimensional. Esto lo hace el método linearOffset. Pensándolo un poco, descubrimos que hay dos fórmulas: una aplica cuando la posición está sobre el borde superior o derecho, y la otra si está sobre el inferior o izquierdo.

Cuando la posición pedida no está en el borde del cuadrado actual, procedemos con el cuadrado inmediatamente interior. Este cuadrado interior tendrá 2 celdas menos de lado que el actual. Obsérvese que nunca nos importa si empezamos desde un cuadrado más externo al actual: un cuadrado de 3 x 3 es exactamente lo mismo ya sea que hayamos partido de 3 x 3, o que hayamos partido de uno de 7 x 7 bajando hasta 3 x 3. Por eso el problema se puede resolver en términos de anillos individuales: si no me sirve el actual, me lo saco de encima y reintento con el que sigue, como quien quita las capas de una cebolla.

Lo que tenemos que tener en cuenta al bajar al cuadrado inferior es ajustar la posición, porque esta fue informada como relativa al cuadrado actual. Lo que ahora es (1, 1), para el cuadrado inferior es (0, 0). Ese ajuste lo hace la clase Pos con el método shiftIn.

sábado, 25 de abril de 2009

Y hablando de diseño de APIs...

Hay que ver esta presentación de Joshua Bloch: How to design a good API and why it matters . Es fabulosa.

miércoles, 22 de abril de 2009

Leyendo XML en Java sin dolor

Leer XML en Java es un verdadero pain in the ass, a diferencia de Scala, que tiene soporte nativo para XML. No estoy muy al tanto de librerías que facilitan la tarea, que las debe haber, pero quiero compartir una muy elemental que hice. Las características de su diseño que, creo, la hacen interesante son:
  • Inmutabilidad
  • Acceso a subnodos por invocaciones encadenadas, evitando NPE ante nodos inexistentes
El primer punto es una verdad a medias, porque se encapsula un org.w3c.dom.Node que podría ser modificado por afuera. Esto se solucionaría clonando el nodo. Esta "librería" es simplemente un wrapper sobre el nodo. Cada instancia es creada para un nodo específico y no se le puede asignar otro; pero el nodo en sí es mutable.
El segundo punto se basa en el patrón Null Object: la idea es prescindir de null en el API para evitar el fatídico Null Pointer Exception. Más abajo lo vemos.
Como dije antes la librería es elemental, y sus limitaciones son:
  • No sirve para "recorrer" el XML sino para obtener elementos conocidos
  • No accede a los atributos de los elementos
No sería nada complicado superar esas limitaciones. Pero no es tanto por la utilidad de la librería que escribo este post sino porque me parece un buen ejemplo de API, las ideas son aplicables a otras cosas. Aparte también ilustra la idea de tener una capa de abstracción sobre una librería existente, cuando los casos de uso son lo suficientemente simples, y se desea que el código refleje claramente la intención sin que uno deba perderse en la complejidad (o torpeza) de la librería original.


API de XmlNode

Esta es la firma de los constructores:
   
   public XmlNode();
   public XmlNode(Node node);
   public XmlNode(Document doc);
El primero es el Null Object, y si bien es un constructor público, lo normal será que sólo se utilice desde la misma clase y no desde afuera. El segundo toma un Node y el tercero un Document. Este último toma el nodo raiz del documento. La idea es que podamos partir de un documento o un nodo cualquiera, y olvidarnos de la diferenciación: lo que tenemos es un árbol de nodos.
    
    public String getName();
    public String getValue();

Con estos métodos obtenemos el nombre (tag) y el valor (contenido) del nodo. Ambos retornarán null si es un Null Object.

    public XmlNode subNode(String tagName);

Este método en cambio nunca retorna null y permite invocaciones encadenadas. El argumento debe ser un tag de un nodo hijo (inmediatamente relacionado con el actual). Veamos un ejemplo. Si creamos un XmlNode a partir de esto:

   <a> 
      <b>
         <c>hola</c>
         <d>que tal</d>
      </b>
   </a>

Podremos accederlo así:

   String nombre = nodo.getName(); // "a"
   XmlNode nodoB = nodo.subNode("b"); // subnodo <b>
   XmlNode nodoC = nodo.subNode("b").subNode("c"); // subnodo <c>
   String valor1 = nodo.subNode("b").subNode("d").getValue(); // "que tal"
   String valor2 = nodoC.getValue(); // "hola"

Y también así:

   XmlNode nodoX = nodo.subNode("z").subNode("y").subNode("x");
   String valor3 = nodoX.getValue(); // null

Ahí vemos la invocación encadenada con nodos inexistentes. En nodoX nos quedó un Null Object. Para verificar si el XmlNode "está definido" o es nulo, tenemos también el siguiente método (inspirado en el homónimo de Option en Scala):

    public boolean isDefined();

Así será más prolijo verificar si el nodo existe, en lugar de ver si getName() o getValue() retornan null.

El código

import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class XmlNode
{
    protected Node node = null;
    
    public XmlNode()
    {
    }
    
   public XmlNode(Node node)
    {
        this.node = node;
    }
    
    public XmlNode(Document doc)
    {
        this.node = doc.getDocumentElement();
    }
    
    public XmlNode subNode(String tagName)
    {
        if(node != null)
        {
            NodeList nl = node.getChildNodes();
            for(int i = 0; i < nl.getLength(); i++)
            {
                Node n = nl.item(i);
                
                if(n.getNodeName().equals(tagName))
                {
                    return new XmlNode(n);
                }
            }
        }
        return new XmlNode();
    }
    
    public String getName()
    {
        return !this.isDefined()? null : node.getNodeName();
    }
    
    public String getValue()
    {
        return !this.isDefined()? null : node.getFirstChild().getNodeValue();
    }
    
    public boolean isDefined()
    {
        return this.node != null;
    }
}

sábado, 4 de abril de 2009

Una vuelta de tuerca más a la generación del diagrama

En el post anterior vimos cómo generar un diagrama Nassi-Schneiderman con tablas HTML. Hicimos un generador abstracto que nos permitiría hacer implementaciones alternativas, es decir, el diseño es modularizable.

trait Generator[T] {
  def nullResult:T
  def generate(o:Option[Node]):T = o match {
    case Some(x) => generate(x)
    case _ => nullResult
  }
  def generate(n:Node):T
}

En nuestro generador de HTML, el parámetro de tipo fue String, naturalmente, ya que generamos HTML con Strings. ¿Habrá sido una exageración parametrizar ese tipo? ¿Se les ocurre un generador que use un tipo diferente a String? 

¿Y por qué no generar el diagrama como imagen? Un poco de AWT no hace mal. Mi nueva implementación usa java.awt.Image. Así es como se ve el nuevo diagrama (a partir del mismo código usado como entrada en el post anterior):


Creo que no hace falta explicar nada, el diagrama habla por sí mismo... sólo acotar que, en los IF que no tienen sección ELSE, en vez de dividir el cuadro por la mitad, hice un 90%/10% para evitar que se ocupe mucho espacio con la parte vacía. Faltan algunas mejoras, como incluir el nombre del módulo, los parámetros y la sección de declaraciones; y parametrizar el ancho de la imagen, que ahora está hardcodeado. En cuanto al alto, debería poder ser calculado según el largo del código, pero no lo resolví y por ahora también está hardcodeado. Definí las siguientes clases auxiliares inmutables, porque esto tiene uso intensivo de "puntos" y "áreas":

case class Point(x:Int, y:Int)

case class Area(start:Point, end:Point) {
  lazy val width = end.x - start.x
  lazy val height = end.y - start.y
  lazy val middleX:Int = start.x + (width / 2) 
  lazy val middleTop = Point(middleX, start.y)
  lazy val middleBottom = Point(middleX, end.y)
  lazy val leftBottom = Point(start.x, end.y)
  lazy val leftTop = start
  lazy val rightTop = Point(end.x, start.y)
}

Los valores definidos en Area son útiles para que el código sea más claro. Si fueran funciones, el código se ejecutaría en cada invocación. Al ser val, el código se ejecuta a lo sumo una vez: el valor queda "recordado" para subsiguientes referencias. Y son lazy para que no se ejecuten hasta ser referenciados.

case object Area {
  def apply(a1:Area, a2:Area):Area = 
      Area(Point(a1.start.x min a2.start.x, a1.start.y min a2.start.y),
           Point(a1.end.x max a2.end.x, a1.end.y max a2.end.y))
}

Con esto logramos que Area pueda ser usado como función, pasando dos áreas como argumentos. El resultado será un área que abarque completamente a esas dos. Esto fue necesario para, luego de procesar ambas secciones de un IF, obtener el área completa de la estructura (ya que cada sección tiene una altura independiente, según el código contenido). Finalmente, el generador:

trait ImageGenerator extends Generator[Image] {
  def imageWidth:Int
  val totalWidth = imageWidth
  val imageHeight = 800
  def nullResult = null

  def generate(n:Node):Image = {
    val img = new BufferedImage(imageWidth, imageHeight, BufferedImage.TYPE_BYTE_BINARY)
    val g = img.createGraphics
    g.setPaint(Color.WHITE)
    g.fillRect(0, 0, imageWidth, imageHeight)
    g.setPaint(Color.BLACK)
    (new GraphicsImageGenerator(g)).generate(n, totalWidth - 20, Point(10,20))
    img
  }
}

El método abstracto imageWidth deberá ser implementado por quien use este trait, para indicar el ancho de imagen deseado. La altura en cambio, viene horriblemente hardcodeada de fábrica, por ahora. Obviamente esto no es todo, el trabajo sucio lo hace otra clase, a la que llamé GraphicsImageGenerator. El método generate crea la Image que vamos a retornar. Inicializa el correspondiente objeto Graphics y se lo pasa a una nueva instancia de GraphicsImageGenerator. Ésta también define un método generate pero requiere argumentos adicionales: aparte del Node, necesita saber con qué ancho cuenta para dibujarlo, y a partir de qué punto. Estos valores se calcularán para cada nodo a dibujar, aquí sólo se envían los valores iniciales que corresponden al nodo raíz del AST. 

Y ahora sí, les dejo esa clase para que escudriñen si tienen ganas.

class GraphicsImageGenerator(val g:Graphics2D)
{
  val lineHeight = 11
  val stmtSep = 3
  val stmtHeight = 15
  val loopThickness = 15

  private def wrap(s:String, w:Int) = (new LineBreaker(s, w, g.getFontMetrics)).getSubtrings
  private def widthOf(ss:List[String]) = ((ss map g.getFontMetrics.stringWidth) :\ 0)(_ max _)
  private def drawRect(a:Area) = g.drawRect(a.start.x, a.start.y, a.end.x - a.start.x, a.end.y - a.start.y)
  private def drawLine(p1:Point, p2:Point) = g.drawLine(p1.x, p1.y, p2.x, p2.y)
  
  private def drawJustified(text:String, w:Int, p:Point, drawRect:Boolean)(fx:(Int, Int, Int) => Int) : Area = {
    val substrings = wrap(text, w)
    var y = p.y + stmtHeight
    substrings foreach { s =>
      g.drawString( s, fx(p.x, g.getFontMetrics.stringWidth(s), w), y)
      y += lineHeight
    }
    Area(p, Point(p.x + w, y))
  }
  private def drawLeftJustified(text:String, w:Int, p:Point) = drawJustified(text, w, p, false) {
    (x:Int, textWidth:Int, w:Int) => x
  } 
  private def drawRightJustified(text:String, w:Int, p:Point) = drawJustified(text, w, p, false) {
    (x:Int, textWidth:Int, w:Int) => (x + w) - textWidth
  } 
  private def drawCentered(text:String, w:Int, p:Point) = drawJustified(text, w, p, true) {
    (x:Int, textWidth:Int, w:Int) => (x + (w / 2)) - (textWidth / 2)
  } 
  
  def generate(n:Node, w:Int, p:Point):Point =
    n match {
      case stmt:Stmt => 
            drawLeftJustified(stmt.s, w, p).leftBottom
      case loop:Loop => 
            val areaLoop = drawLeftJustified(loop.head, w, p)
            val startCode = Point(p.x + loopThickness + 2, areaLoop.end.y + 2)
            val loopBodyBottom = generateCode(loop.body, (w - 4) - loopThickness, startCode)
            val endPoint = Point(areaLoop.end.x, loopBodyBottom.y)
            drawRect(Area(startCode, endPoint))
            drawRect(Area(areaLoop.leftTop, endPoint))
            Point(p.x, endPoint.y)
      case cond:Cond => 
            val areaCond = drawCentered(cond.c, w, p)
            drawRect(areaCond)
            val sepStart = if(cond.cElse.isEmpty) Point(p.x + (w * .9).asInstanceOf[Int], areaCond.end.y) else areaCond.middleBottom
            val thenWidth = if(cond.cElse.isEmpty) (w * .9).asInstanceOf[Int] - 4 else (w/2) - 4 
            drawLine(areaCond.leftTop, sepStart)
            drawLine(areaCond.rightTop, sepStart)
            val pointThen = generateCode(cond.cThen, thenWidth, Point(p.x + 2, areaCond.end.y + 2))
            val pointElse = generateCode(cond.cElse, (w/2) - 4, Point(p.x + 2 + (w/2), areaCond.end.y + 2))
            val areaCode = Area(areaCond.leftBottom, Point(areaCond.end.x, pointThen.y max pointElse.y))
            drawRect(areaCode)
            drawLine(sepStart, Point(sepStart.x, areaCode.end.y))
            areaCode.leftBottom
      case block:Block => 
            val codeEndPoint = generateCode(block.content, w - 4, Point(p.x + 2, p.y + 2))
            val endPoint = block.exceps match {
              case None => codeEndPoint
              case Some(es) => generate(es, w - 4, codeEndPoint)
            }
            drawRect(Area(p, Point(p.x + w, endPoint.y)))
            endPoint
      case excepSection:ExcepSection =>
            generateCode(excepSection.ee, w, p)
      case whenExcep:WhenExcep =>
            val areaWhen = drawLeftJustified(whenExcep.e, w - loopThickness, Point(p.x + loopThickness, p.y))
            val endPoint = generateCode(whenExcep.body, w, Point(p.x, areaWhen.end.y))
            drawLine(p, Point(p.x + w, p.y))
            drawLine(Point(p.x + loopThickness, p.y), Point(p.x, p.y + loopThickness))
            drawLine(Point((p.x + w) - loopThickness, p.y), Point(p.x + w, p.y + loopThickness))
            endPoint
      case module:Module => generate(module.body, w, p)
      case _ => p
    }    

  private def generateCode(codeList:List[Node], w:Int, p:Point):Point =
    (p /: codeList) { (start:Point, c:Node) => generate(c, w, start) }
}

Nota: no incluyo la clase LineBreaker, que sirve para cortar un String en varios según sea necesario para que el texto entre en un ancho gráfico determinado.

jueves, 2 de abril de 2009

Parseando en Scala (6): Generando la salida

Nuestro propósito era parsear código PL/SQL, cosa que ya vimos en los posts anteriores, y generar como salida un diagrama estructurado. 

Vamos a usar el siguiente código PL/SQL para probar el experimento. No importa lo que hace, es cualquier cosa que se me ocurrió.

PROCEDURE MYPROC (Param IN NUMBER) IS
 AUXVAR VARCHAR2(10) := NULL;
begin
 IF Param = 1 THEN
  AUXVAR = 'A';
 ELSIF Param = 2 THEN
  AUXVAR = 'B';
 END IF;

 if AUXVAR IS NOT NULL
 THEN
  FOR RECORD IN (SELECT * FROM MYTABLE WHERE FLD = AUXVAR)
  LOOP
   IF RECORD.EXPIRY <= SYSDATE 
   THEN
    LOG_EXPIRED(RECORD.ID);
   END IF; 
  END LOOP;   
 END IF;      
 
 dbms_output.put_line('END OF MYPROC WITH PARAM = ' || Param); 
 
 exception  
 when others then 
  dbms_output.put_line('OOPS!'); 
end; 

Y vemos antes que nada el resultado que obtuve, tal como lo veo en el navegador. Como decíamos, es una versión HTML del diagrama Nassi-Schneidermann donde tenemos una representación visual de la estructura lógica. 


Cada IF es un recuadro, con un encabezado que indica la condición (seguida de un signo de pregunta), y se divide en dos secciones: por convención, la izquierda corresponde a verdadero y la derecha a falso (THEN y ELSE respectivamente). Se puede ver cómo los IF encadenados con ELSIF quedaron resueltos como IFs anidados. Los ELSE vacíos también se dibujan, con "---". Los ciclos, como el FOR del ejemplo, son recuadros que muestran a la izquierda y en verde la cláusula correspondiente, y a la derecha el código. La sección EXCEPTION se muestra al final del recuadro del bloque debajo de una línea punteada. 

Esto es generado por un módulo a partir del AST  obtenido por el parseador. Pero el generador de HTML no tiene por qué ser la única opción de generación del diagrama, de hecho ya tengo un generador alternativo que comentaré más adelante. El punto es que para permitir la modularización, armamos una jerarquía de traits. El siguiente trait es el padre de los generadores.

trait Generator[T] {
 def nullResult:T
 def generate(o:Option[Node]):T = o match {
  case Some(x) => generate(x)
  case _ => nullResult
 }
 def generate(n:Node):T
}

Si recordamos, Node es el supertipo del modelo  que estamos usando. El parámetro de tipo, T, es necesario porque para las posibles salidas pueden usarse diferentes tipos; de hecho esto es resultado de refactorizar mi código para permitir el generador alternativo en forma elegante. Con el método abstracto generate, requerimos que todos los generadores implementen la "transformación" de un Node cualquiera (de todos los posibles según el modelo), en algo de tipo T. Para la generación HTML ese tipo será String. Agregué una implementación default de generate que, en vez de tomar un Node toma un Option[Node]. Si se trata de un nodo definido, se deriva el control al método abstracto recién mencionado, y si no, a otro que define cómo se representa algo "vacío" para el tipo T. Esto me pareció práctico porque el modelo suele tener relaciones con opcionalidad: así puedo invocar indistintamente la generación de un nodo concreto o de un nodo que puede estar presente o no. Finalmente, el generador que hace todo el trabajo:

trait HTMLGenerator extends Generator[String] {
  def nullResult = ""
  def generate(n:Node):String = n match {
    case Stmt(s) => s.replace("<","&lt;") + "<br>\n"
    
    case WhenExcep(e,body) => "<p>when " + e + " then<br>\n" + 
      (body map generate).mkString + "</p>\n"
    
    case ExcepSection(s) => openCell("class=\"excsec\"") + 
      "<strong>exception</strong><br>\n" + 
      (for(w <- s) yield generate(w)).mkString +
      closeCell
    
    case Block(stmts, exceps) => "<table>" +
      openCell +
      (stmts map generate).mkString + 
      closeCell +
      (if(exceps.isDefined) generate(exceps.get) else "") +
      "</table><br>\n"
    
    case Loop(h,body) => "<table><tr><td class=\"loop\">" +
      h +
      "</td>\n<td>" +
      (body map generate).mkString +
      "</td></tr></table>\n"     
      
    case Cond(c,ct,ce) => "<table>" +
        openCell("colspan=\"2\" class=\"ifhead\"") + 
        c + 
        "<big><b> ?</b></big>" +
        closeCell + 
        openCell("class=\"ifthen\"") + 
        (ct map generate).mkString + 
        "</td><td class=\"ifelse\">" + 
        (ce match {
          case Nil => "---"
          case xs => (xs map generate).mkString 
        }) + 
        closeCell +
        "</table><br>\n"
    
    case Module(t,n,p,r,v,b) => startHtml + "<h3>" + t + " " + n + "</h3>\n" +
        (p match { case Some(x) => generate(x); case None => "" }) + "<br>\n" +
        (if(v != Nil) "<table>" + openCell + (v map generate).mkString + closeCell + "</table>" else "") +
        "<hr><br>" + generate(b) + endHtml
  }

  private val startHtml = "<html><head><style type=\"text/css\">\n" +
     "table { width: 100%; border: solid thin }\n" +
     ".comment { color: darkgreen; font-style: italic }\n" +
     ".ifhead { background-color: moccasin; text-align: center }\n" +
     ".ifthen { border-top: solid thin; border-right: solid thin; }\n" +
     ".ifelse { border-top: solid thin; border-left: solid thin; }\n" +
     ".excsec { border-top: dashed thin; }\n" +
     ".loop { border-right: solid thin; background-color: MediumAquamarine; }\n" +
     "</style></head><body>\n"
  
  private def openCell(modif:String) = "<tr><td " + modif + ">"
  private def openCell:String = openCell("")
  private val closeCell = "</td></tr>"  
 
  private val endHtml = "</body></html>"
}

Definimos nullResult, para los nodos opcionales que no estén presentes, como un String vacío. Implementamos generate haciendo pattern matching sobre el nodo recibido. Contemplamos todos los tipos de nuestro modelo y generamos la representación HTML deseada para cada uno. Los detalles de la implementación puede que no sean del todo claros a primera vista, pero la idea sí, es bien simple. 

El nodo Module siempre estará en la raiz del AST, por eso es el encargado de especificar el comienzo y el final del documento HTML. Entre una cosa y la otra, se producirán todas las invocaciones recursivas de generate para los nodos contenidos en el árbol. Los estilos CSS acá están hardcodeados, pero idealmente serían customizables. 

Con esto finalizamos la serie, aunque me parece que habrá un bonus.

domingo, 8 de marzo de 2009

Parseando en Scala (5): El código

A continuación, el módulo para parsear PL/SQL en Scala. Insisto en que no es un parseador completo, pero por ahora me sirve así nomás. Disculpen si ven alguna desprolijidad... más abajo explico algunas cosas.

import scala.util.parsing.combinator.ImplicitConversions
import scala.util.parsing.combinator.syntactical.StdTokenParsers

class PLParser extends StdTokenParsers with ImplicitConversions {
type Tokens = PLLexical
val lexical = new PLLexical
lexical.delimiters ++= Set(";")
lexical.reserved ++= Set("procedure","begin","end","if","then","else","is","as","elsif",
                        "when","exception","loop","for","while", "function", "declare")

def regularStr: Parser[String] = rep1(ident | stringLit | "is") ^^ {s => s.mkString(" ")}

def stmt: Parser[Stmt] = regularStr <~ ";" ^^ {s => Stmt(s.mkString(""))}

def varDecl:Parser[Stmt] = (regularStr ~ opt("exception")) <~ ";" ^^      {(s:String,e:Option[String]) => Stmt(s.mkString("") + " " + e.getOrElse(""))}

def params: Parser[Stmt] = rep1(ident) ^^ {s => Stmt(s.mkString(" "))}

def loop: Parser[Loop] = "loop" ~> rep1(code) <~ ("end" ~ "loop" ~ ";") ^^ { c => Loop("loop", c) }

def forWhileLoop: Parser[Loop] = ("while" | "for") ~ (regularStr <~ "loop") ~ (rep1(code) <~ ("end" ~ "loop" ~ ";")) ^^ { (t:String, h:String, c:List[Code]) => Loop(t + " " + h, c) }

def cond: Parser[Cond] = (
 ("if" ~> regularStr <~ "then") ~ rep1(code) ~ rep(("elsif" ~> regularStr <~ "then") ~ rep1(code)) ~ opt("else" ~> rep1(code)) <~ ("end" ~ "if" ~ ";")) ^^ { (sif:String, ifthen:List[Code], elsifs:List[String ~ List[Code]], ifelse:Option[List[Code]]) =>
   val startCond = Cond(sif, ifthen, Nil)
   buildCond(startCond, elsifs, ifelse)
 }

def block: Parser[Block] = ("begin" ~> rep1(code)) ~
 opt("exception" ~> rep1(whenExcep)) <~ ("end" ~ opt(ident) ~ ";") ^^ {(s:List[Code], es:Option[List[WhenExcep]]) =>
  Block(s, if(es.isDefined) Some(ExcepSection(es.get)) else None) }

def code = stmt | block | cond | loop | forWhileLoop

def whenExcep: Parser[WhenExcep] = ("when" ~> ident <~ "then") ~ rep1(code) ^^ { (e:String,s:List[Code]) => WhenExcep(e,s) }

def excepSection: Parser[ExcepSection] = "exception" ~> rep1(whenExcep) ^^ { ee => ExcepSection(ee) }

def procedure: Parser[Module] = (
   ("procedure" ~> ident) ~
   opt(params) ~
   (("is" | "as") ~> rep(stmt)) ~
   block) ^^
   {(s:String, p:Option[Stmt], v:List[Stmt], b:Block) => Module(MTProcedure, s, p, None, v, b)}

def function: Parser[Module] = (
   ("function" ~> ident) ~
   opt(params) ~
   ("return" ~> regularStr) ~
   (("is" | "as") ~> rep(stmt)) ~
   block) ^^
   {(s:String, p:Option[Stmt], rt:String, v:List[Stmt], b:Block) => Module(MTFunction, s, p, Some(rt), v, b)}

def anonModule: Parser[Module] = (
   ("declare" ~> rep(varDecl)) ~ (opt("is" | "as")  ~> block)) ^^
   {(v:List[Stmt], b:Block) => Module(MTAnonymousBlock, "", None, None, v, b)}

def module: Parser[Module] = anonModule | procedure | function

private def buildCond(c:Cond, elsifs:List[String ~ List[Code]], ifelse:Option[List[Code]]):Cond = elsifs match {
 case Nil => Cond(c.c, c.cThen, ifelse getOrElse Nil)
 case x::xs => x match {
   case i ~ ss => Cond(c.c, c.cThen, List(buildCond(Cond(i, ss, Nil), xs, ifelse)))
 }
}

}


Extendemos StdTokenParsers porque allí se definen algunos Parsers básicos que aprovecharemos. ImplicitConversions incluye conversiones útiles para usar el operador ^^.

El trait StdTokenParsers requiere la definición de Tokens como subtipo de StdTokens:

trait StdTokenParsers extends TokenParsers {
 type Tokens <: StdTokens         // ...   }  


Podríamos haber declarado que el type Tokens fuese StdLexical, un parser léxico provisto por la librería estándar de Scala. En cambio usamos PLLexical, que es lo mismo pero sin diferenciar entre mayúsculas y minúsculas, porque así es PL/SQL. Ese módulo lo agregué yo al proyecto pero no lo vamos a copiar acá, sólo tengan en cuenta que StdLexical asume código case-sensistive. Si el código a parsear no lo es, hay que meter mano por ahí. 
Declaramos un objeto lexical de tipo PLLexical. 
Como se muestra, agregamos los delimitadores que corresponda (el punto y coma finaliza sentencias en PL/SQL), y una colección de palabras reservadas. Todas las palabras que yo quiera reconocer al definir los parser combinators deben estar en esta lista para que todo funcione. 
Y listo, el resto son todas las funciones para parsear el lenguaje en cuestión como se explicó en la entrada anterior
La definición de regularStr como "cadena regular" es auxiliar, me sirve como base para otros parsers para los que no necesito reconocer la estructura interna: sentencias, declaraciones de variables, y expresiones. Se define como una repetición arbitraria de ident (identificadores, definido en StdTokenParsers), stringLit (literales de cadena, idem) y la palabra reservada "is". 
Un sentencia (stmt) se define como un regularStr seguido del delimitador ";". Una declaración de variable también puede ser aceptada como una sentencia con la salvedad de que si define una excepción termina en "exception"... al ser ésta una palabra reservada según indicamos arriba, no entrará como parte de un stringLit. Obsérvese cómo, a pesar de que varDecl es una definición diferente a stmt, en ambos casos generamos un nodo Stmt, porque no necesitamos mayor detalle en el modelo
Si me vinieron siguiendo en esta serie, las piezas deberían estar encajando. Voy a detenerme un poco en la definición de cond. Al principio comentaba los problemas que tenía para parsear el ELSIF en previos intentos. El ELSIF de PL/SQL permite un aspecto "aplanado" a lo que en el fondo son IFs anidados. En un diagrama desearíamos ver ese anidamiento correctamente, por lo tanto debemos reconstruirlo. Así es cómo lo logré: 

def cond: Parser[Cond] = (
 ("if" ~> regularStr <~ "then") ~ rep1(code) ~    rep(("elsif" ~> regularStr <~ "then") ~ rep1(code)) ~    opt("else" ~> rep1(code)) <~    ("end" ~ "if" ~ ";")) ^^    { (sif:String, ifthen:List[Code], elsifs:List[String ~ List[Code]],       ifelse:Option[List[Code]]) =>
   val startCond = Cond(sif, ifthen, Nil)
   buildCond(startCond, elsifs, ifelse)
}

Lo que vemos a la izquierda del ^^ es simplemente el cuasi-EBNF que describe la estructura de los IF: el bloque THEN es obligatorio (rep1), los ELSIF pueden no existir o ser varios (rep), y el ELSE final es opcional (opt). Para construir el nodo, me valgo de esta función auxiliar recursiva:
 private def buildCond(c:Cond, elsifs:List[String ~ List[Code]],
             ifelse:Option[List[Code]]):Cond = elsifs match {
   case Nil => Cond(c.c, c.cThen, ifelse getOrElse Nil)
   case x::xs => x match {
     case i ~ ss => Cond(c.c, c.cThen, List(buildCond(Cond(i, ss, Nil), xs, ifelse)))
   }
 }

Finalmente, les muestro cómo podemos crear una aplicación que invoque el parser:
object PLParserMain extends Application with PLParser {
 val theCode = // ... obtener el código de un archivo o la fuente que corresponda
 val result = module(new lexical.Scanner(theCode.toString))
 result match {
  case Success(e, _) => Console.println("OK!\n" )
  case Failure(msg, _) => Console.println("[Failure] " + msg)
  case Error(msg, _) => Console.println("[Error] " + msg)
 }
}

Al extender PLParser, estamos integrando todo lo que ese trait define a nuestro objeto aplicación. Vemos cómo pasar el código al parser de módulo (module, que definimos en PLParser), porque un módulo es lo que esperamos encontrar como primer nivel en el código a parsear, y resultará en un nodo Module como raíz del AST.

Claro que hasta acá no hicimos más que parsear y reportar un resultado: OK, falla o error. En el case Success tenemos disponible el AST completo (en este caso bajo el nombre e) con el que podemos hacer lo que se nos ocurra.

Sobre eso, más en la próxima...

Actualización 16/5/09:  La versión actual de PLParser tuvo varias mejoras respecto a la publicada en este post. Ahora el modelo diferencia a las sentencias de las declaraciones de variables y los parámetros. Para eso tuve que, entre otras cosas, definir más símbolos como delimiters aparte del punto y coma. Ya no utilizo esa bolsa de gatos del "regularStr".

miércoles, 25 de febrero de 2009

Parseando en Scala (4): Combinator Parsing en acción

Leemos en el scaladoc del trait Parsers:
(...) El término "parser combinator" se refiere al hecho de que estos parsers son construidos a partir de parsers primitivos y operadores de composición, como secuenciación, alternación, opcionalidad, repetición, etc. Un parser primitivo es un parser que acepta o rechaza una porción de la entrada, en base a cierto criterio. (...)
En la segunda parte de esta serie mencionábamos estas posibilidades de "composición" al definir la sintaxis: que algo se pueda repetir, que algo sea opcional, etc. EBNF utiliza determinados símbolos para esos operadores de composición. Este es un ejemplo de Wikipedia donde se define la sintaxis para escribir un número en un lenguaje hipotético.


number = [ "-" ] , digit , { digit } ;


Esta definición se lee así:
  • Opcionalmente se comienza con un guión (signo menos). Los corchetes indican opcionalidad.
  • Se sigue con un dígito. La coma indica sucesión de elementos.
  • Se sigue con 0 a n dígitos. Las llaves indican repetición arbitraria.
Esto asume que en alguna otra parte se definió lo que es un "digit" de la misma manera que aquí se define lo que es un "number".

En Scala se traduciría más o menos a algo así:

def number: Parser[Number] = opt("-") ~ digit ~ rep(digit) // luego completamos lo que falta

Este sencillo ejemplo ilustra cómo se traduce en forma bastante directa desde la notación EBNF.
  • Opcionalidad: método opt()
  • Sucesión: símbolo ~ (que en realidad es un método)
  • Repetición arbitraria: método rep()
Con una vuelta de tuerca más: el método rep1() es similar a rep() pero requiriendo que exista como mínimo una ocurrencia (1 a n). La misma definición se puede simplificar a:

def number: Parser[Number] = opt("-") ~ rep1(digit) // ...

El tipo de retorno es Parser[X] donde X es una clase del modelo. En este caso supongamos que se definió la clase Number como parte del modelo.

También vamos a usar el símbolo | para indicar alternativas. Si contempláramos también el signo + para escribir un número positivo, haríamos así:

def number: Parser[Number] = opt("-" | "+") ~ rep1(digit) // ...

Como se puede ver, combinamos los operadores según nuestra necesidad: opcionalmente habrá un signo, y el signo puede ser - o +.

Estamos listos para parsear PL/SQL. Como primer ejemplo veamos la definición del LOOP:

def loop: Parser[Loop] = "loop" ~ rep1(code) ~ ("end" ~ "loop" ~ ";") // ...

Desde luego, esto requiere la definición de code retornando un Parser[Code], y así con todas las dependencias.
Todo lo que sea whitespace no es necesario especificarlo: entre elementos puede haber cualquier cantidad de espacios, tabs o line feeds. Observar que como fin del loop usamos ("end" ~ "loop" ~ ";"), porque si usáramos "end loop;" estaríamos reconociéndolo solamente si se escribe exactamente así.

Sigamos con este ejemplo. Esta definición, así como está, no retorna un Parser[Loop]: vamos a completarla. Tenemos que agregar una función (una closure para mayor comodidad) que levante esos elementos parseados y genere un objeto del modelo, en este caso Loop. Pero antes, tenemos que usar variantes del operador ~. Las variantes ~> y <~ son equivalentes a ~ en tanto que indican secuencia de elementos, la diferencia está en que "señalan" el elemento que nos interesa recuperar a fines de construir un nodo del AST, lo que implica que la parte no señalada será ignorada. Para armar el nodo Loop, lo único que necesito de esa definición es la colección de objetos Code. Entonces "señalemos" lo que realmente importa:


def loop: Parser[Loop] = "loop" ~> rep1(code) <~ ("end" ~ "loop" ~ ";") // esto arroja un List[Code]

Ahora sí: rep1(code) produce un List[Code], y eso es lo que la closure tomará como entrada. La closure en cuestión es sencillísima:

{ c:List[Code] => Loop("loop", c) }

(Uso el string "loop" para indicar que no es un FOR ni un WHILE, este es un detalle de mi implementación que no tiene mucha importancia).
Terminamos juntando la definición de la sintaxis y la closure de generación del nodo con el simpático operador ^^.

def loop: Parser[Loop] = "loop" ~> rep1(code) <~ ("end" ~ "loop" ~ ";") ^^ { c => Loop("loop", c) }

Voilà! Y simplificamos la closure dejando que el compilador infiera el tipo del argumento. Todo esto es type-safe, el compilador chilla si nos equivocamos con los tipos.
Insisto, nada de esto es magia, estamos usando una librería estándar. Estos operadores raros son métodos de la clase Parser. Y si bien a primera vista el código parece un jeroglífico, es sólo cuestión de aprender el API como un "sublenguaje": todo cobra sentido, y de hecho parsear termina siendo una pavada. Cada elemento se define con una parte declarativa (equivalente a un EBNF), el operador ^^, y una closure que toma lo necesario de esa declaración para crear un nodo del AST.

Para parsear los FOR y WHILE utilizo una definición unificada porque son muy similares, y también genero un nodo Loop:

def forWhileLoop: Parser[Loop] = ("while" | "for") ~ (regularStr <~ "loop") ~ (rep1(code) <~ ("end" ~ "loop" ~ ";")) ^^ { (t:String, h:String, c:List[Code]) => Loop(t + " " + h, c) }

Esta declaración produce tres cosas relevantes, tomadas como parámetro por la closure: un String que será "while" o "for", un String con la condición o secuencia del FOR, y la correspondiente List[Code].

En la próxima entrega muestro el contexto donde se define todo esto y vamos cerrando lo que es parseo, para más adelante empezar a explotar el AST.

sábado, 21 de febrero de 2009

Parseando en Scala (3): Modelo

Retomando, decíamos que el resultado de parsear es generar un abstract syntax tree (AST). Vamos a ser un poco más gráficos, para que no queden dudas de que se trata de algo bien facilongo.

Si el código PL/SQL a parsear fuera éste:

PROCEDURE myproc IS
BEGIN
s1;
s2;
IF cond1 THEN
s3;
ELSE
s4;
WHILE cond2 LOOP
s5;
s6;
IF cond 3 THEN
s7;
END IF;
END LOOP;
s8;
END IF;
END;
...nuestro objetivo lo vemos plasmado en este garabato:

Se ve bien clarita en el árbol la estructura sintáctica del código parseado. El árbol no es más que un grafo, compuesto por nodos y relaciones entre ellos.

Podemos identificar distintos tipos de nodos. En el dibujito, cada tipo de nodo está pintado de un color diferente (las sentencias en amarillo, etc.) Las relaciones (líneas) indican los subnodos. Las sentencias son nodos terminales, nunca tienen subnodos.

Para armar el AST necesitamos modelar los tipos de nodo, cada uno con sus características. Verán cómo la orientación a objetos convive en armonía con la programación funcional: el modelo es una jerarquía de clases. Todos los tipos de nodo son subclase de un nodo abstracto, pero también identifiqué una abstracción en el medio a la que llamé Code, ya veremos por qué. Este sería un pseudo-UML del modelo:



Y en Scala:

abstract class Node
abstract case class Code extends Node
case class Stmt(s: String) extends Code
case class Cond(c: String, cThen: List[Code], cElse: List[Code]) extends Code
case class Loop(head:String, body: List[Code]) extends Code
case class WhenExcep(e: String, body: List[Code]) extends Node
case class ExcepSection(ee: List[WhenExcep]) extends Node
case class Block(content: List[Code], exceps:Option[ExcepSection]) extends Code
case class Module(typ: ModuleType, name: String, pars: Option[Stmt],
returns: Option[String], vars: List[Stmt], body: Block) extends Node

Como se puede ver, ninguna de estas clases define métodos; sólo atributos, que son seteados como parámetros del constructor. Además, son inmutables. El contenido relevante de cada tipo de nodo está en los parámetros: esto determina qué tipo de relaciones con subnodos puede tener en el grafo.

Para las colecciones de elementos, usamos List[T], la lista inmutable de la librería estándar de Scala. Para los elementos opcionales, usamos Option[T], cuyos posibles valores son Some[T] (con un valor de T específico) o None. Es mejor que manejar la opcionalidad chequeando por la referencia en null, pero no nos vayamos por las ramas. Vamos a comentar un poco el modelo (los que no conozcan PL/SQL, podrán imaginárselo más o menos).

El tipo de nodo "sentencia" (Stmt) sólo contiene un String, que es la sentencia misma en PL/SQL (no nos interesa la estructura interna, nuestro modelo es simplificado). No puede haber subnodos, como decíamos recién.

Las condiciones (Cond) son más complejas: tienen un String (que es la condición en sí), una sección para el "then" y otra para el "else". Cada una de estas secciones podría ser, en principio, una colección de sentencias, pero lo cierto es que puede haber cosas más diversas... ¡por eso fue necesaria la abstracción Code! Estos "elementos de código" pueden ser varias cosas (las cuatro subclases), pero no cualquier Node. El mismo Cond es un Code, y claro, porque puede haber condiciones anidadas.

Podría decirse que la sección "then" debe ser modelada diferente a la sección "else", porque en un IF de PL/SQL, la primera es obligatoria y la segunda opcional. Pero el modelo no necesariamente debe reflejar todas las reglas de sintaxis que aplican al parseo. Mi parser va a dar error si falta el "then", pero no si falta el "else"; eso está contemplado. Pero con una List vacía (Nil) puedo representar un "else" ausente. Asimismo el modelo tampoco refleja que el "then" tendrá por lo menos un elemento.

Con la clase Loop modelo los distintos tipos de loop, no me interesa diferenciarlos. Cada uno contendrá un encabezado (tipo de loop y condición), y un contenido que es lista de Code.

WhenExcep es el "catch" de excepciones de PL/SQL: contiene el nombre de la excepción y la lista de Code asociada.

ExcepSection es la sección final (dentro de un bloque) que contiene una sucesión de WhenExcep.

Block es un bloque BEGIN / END. Consiste en una lista de Code, y opcionalmente una sección de excepciones.

Finalmente, Module representa, obviamente, un módulo, que puede ser un procedimiento, una función o un bloque anónimo de PL/SQL. Tiene un tipo de módulo, un nombre, opcionalmente parámetros (aquí usamos Stmt, no porque los parámetros sean una sentencia, sino por simplificar), opcionalmente un tipo de retorno (aplicable a módulos función), declaraciones / variables (una lista de Stmt, también por simplificar), y un Block, que es el bloque de código de mayor nivel en el módulo.

Para los tipos de módulo uso esta definición:

abstract class ModuleType
case object MTProcedure extends ModuleType { override def toString = "procedure" }
case object MTFunction extends ModuleType { override def toString = "function" }
case object MTAnonymousBlock extends ModuleType { override def toString = "anonymous block" }

En la próxima: vamos a parsear de una vez.

sábado, 14 de febrero de 2009

Parseando en Scala (2): Metasintaxis y AST

Demás está decir que, antes de pretender parsear un lenguaje determinado, tenemos que conocer su sintaxis. Y si la conocemos, debemos ser capaces de expresarla formalmente con una metasintaxis, como podría ser BNF o EBNF. Vamos a poner unos ejemplos del tipo de cosas que podemos definir, y los ilustramos con ejemplos de PL/SQL, nuestro lenguaje a parsear.

símbolos:= (asignación)
palabras clave PROCEDURE
sucesión de elementos IF (seguido de) condición (seguido de) THEN ...
elementos alternativos En una asignación, del lado derecho de := puede haber un identificador o un literal
repetición de elementos (0 a n) En la sección de declaración de variables puede no haber ninguna, una, o varias
repetición de elementos (1 a n) En la sección EXCEPTION debe haber al menos un catch (con la forma WHEN excepción THEN ...)

Con este metalenguaje podemos definir el lenguaje completo. Por si no queda claro, cuando decimos "elemento" podemos estar hablando de definiciones de cualquier nivel en la entrada de texto, desde un carácter "A" hasta un bloque de código BEGIN / END. Es decir, en alguna parte definimos en qué consiste un bloque de código y le ponemos un nombre. Luego podemos definir que un PROCEDURE contiene, además de parámetros opcionales, declaración de variables, etc., un bloque de código. Y como las definiciones pueden ser recursivas, también podremos definir que dentro de un bloque de código puede haber bloques de código. ¿Se va entendiendo lo de "combinators"?

Como decía en el post anterior, los parser combinators en Scala son un ejemplo de DSL (domain specific language), ya que "se sienten" como un BNF, o digamos que se presta a una traducción directa desde un BNF. Si no contamos previamente con el BNF del lenguaje que queremos parsear, como para hacer esa traducción, podemos directamente expresar el lenguaje con los parser combinators. Eso es lo que hice yo en este caso, con la salvedad de que no necesitaba parsearlo en profundidad, sino que para mis fines bastaba con capturar la estructura lógica. Esto simplificó la tarea: no necesito interpretar el contenido de una sentencia simple, para reconocerla me basta con que haya una sucesión de caracteres comunes terminados en punto y coma. No importa si hay una asignación, una llamada a un procedimiento, un query, etc.; las sentencias simples las muestro en mi diagrama tal como vienen.

Nuestro cuasi-BNF en Scala no es una mera declaración sino que es a la vez el código que parsea. Lo que tenemos que agregarle es qué hacer con las estructuras que va reconociendo. El que pensó en renderizar la salida, que se retire por favor. Dijimos que vamos a separar las responsabilidades como corresponde.

Con ustedes, el AST

El objetivo inmediato de parsear debe ser obtener el abstract syntax tree, es decir, una representación de la estructura parseada. Una vez que conseguimos esto, nos olvidamos del texto de entrada y las reglas del lenguaje. Piensen en los compiladores de .NET: la plataforma soporta varios lenguajes, y para cada uno hace falta un parseador diferente. Sin embargo todos conducen a lo mismo, el MSIL, una representación del programa que no mantiene dependencia con el lenguaje de origen. Es un AST. Luego desde el AST generamos la salida deseada. Si nos da el cuero podemos generar byte code ejecutable.

El AST consistirá en un grafo de objetos de un modelo que debemos definir, según la estructura que necesitamos capturar. Ese modelo se define como una serie de clases "nodo". A medida que el cuasi-BNF parsea y detecta estructuras en el texto, indicaremos también qué nodos instanciar en cada caso.

Se está poniendo bueno, sigue en la próxima

viernes, 13 de febrero de 2009

Parseando en Scala (1): Intro

Voy a compartir un ejemplo de programación funcional aplicado en la vida real, para resolver un problema concreto que tuve como desarrollador. Más de una vez me tocó descifrar el fuente de un programa ajeno con una lógica tirada de los pelos (a quién no). Cuando el lenguaje en cuestión es PL/SQL, se me complica tener una buena perspectiva de la estructura del código.
Allá por los '80 en la facultad me enseñaron los diagramas estructurados de Nassi-Schneiderman. Estos diagramas están buenos para leer código estructurado, y a veces garabateo alguno si tengo que armar una lógica complicada. Pero el código ajeno nunca existe en forma de diagrama, así que estaría bueno tener una herramienta que lo genere. Esa herramienta, además de ser útil, podría ser interesante de programar.

Problema #1: Generar el diagrama

Lo más práctico me pareció generar la salida en HTML con tablas, para ver algo parecido al diagrama Nassi-Schneiderman con un browser. Fue una buena opción. Las principales estructuras a visualizar son los condicionales (IF, THEN, ELSE) y los ciclos (FOR, WHILE, LOOP), y la forma en que se anidan.

Problema #2: Interpretar el código original

Dicho de otra manera: parsear. En la primera encarnación de la herramienta, en C++, parseaba a lo guapo, por no decir a lo bestia. No es que no se pueda parsear bien con C++, pero terminé con una implementación con limitaciones absurdas. Me metí en un berenjenal. Antes de parsear me veía obligado a toquetear el código de entrada para adecuarlo a ciertos requisitos inexcusables... por ejemplo, si había una cadena de ELSIF's:


IF cond1 THEN
sentencia1;
ELSIF cond2 THEN
sentencia2;
END IF;


...para que fuera parseable, tenía que modificarlo manualmente a:


IF cond1 THEN
sentencia1;
ELSE
IF cond2 THEN
sentencia2;
END IF;
END IF;


Creo que también hice una versión en C# que andaba mejor, pero el problema de fondo no estaba resuelto.

Combinator parsing al rescate

La técnica funcional salvadora fue combinator parsing, en este caso en Scala. No voy a incluir acá un tutorial de Scala ni voy a explicar cómo está implementada la librería (si bien vale la pena empaparse en el tema). Voy a enfocarme en el uso de la librería usando mi proyecto como ejemplo. Van a notar que parece un lenguaje con soporte especial para parsing, pero es solo una ilusión: el lenguaje es lo suficientemente flexible, porque permite definir operadores como | y ~ en forma de métodos, tiene conversiones implícitas, y un toque de syntax sugar que lo hace óptimo para crear DSLs (domain specific languages). 

Combinator parsing viene incluido en la librería estándar de Scala, y más que un API, parece un sublenguaje. Su implementación puede resultar un tanto sesuda para el no iniciado; pero su utilización, prometo, está al alcance de cualquier programador.

Otro problema que tenían las soluciones anteriores era el acoplamiento entre el parsing y la generación de la salida. Vamos a separar las responsabilidades para que, una vez resuelto el parseo, podamos generar todas las salidas que se nos antoje.

Continuará

sábado, 7 de febrero de 2009

Guía para el código testeable

Siguiendo con los posts "de referencia", hoy traduzco un resumen de la Guía para el Código Testeable utilizada en Google y publicada en el blog de Miško Hevery. Esta guía consiste en 4 fallas de diseño a evitar, y las señales de advertencia que indicarían que las cometimos. Como siempre, se trata de reglas generales, no para seguirlas dogmáticamente, sino para tenerlas presente y considerar el costo de ignorarlas.

Quizás más adelante me ponga a traducir la cosa más a fondo, porque se explica todo con mayor detalle, con argumentos y ejemplos. Mientras tanto, quienes puedan leer inglés, háganse un favor y vayan a la fuente.

Falla #1: El constructor hace trabajo
Señales de advertencia:
  • Se usa el operador new en el constructor o en la declaración de campos
  • Llamadas a métodos static en el constructor o en la declaración de campos
  • Cualquier cosa en un constructor más allá de asignación de campos
  • Objetos que no queden completamente inicializados una vez terminado el constructor (atención con los métodos initialize)
  • Flujo de control (lógica condicional o cíclica) en un constructor
  • Se construye un complejo grafo de objetos dentro de un constructor, en lugar de usar una factory o un builder
  • Bloques de inicialización

Falla #2: Hurgar en los colaboradores
Señales de advertencia:
  • Se pasan objetos pero nunca son utilizados directamente (sólo para obtener acceso a otros objetos)
  • Violación de la ley de Demeter: la cadena de llamadas a métodos recorre un grafo de objetos con más de un punto (.)
  • Nombres sospechosos: context, environment, principal, container, o manager

Falla #3: Estado global riesgoso y Singletons
Señales de advertencia:
  • Uso de singletons
  • Uso de campos static o métodos static
  • Uso de bloques de inicialización static
  • Uso de registries
  • Uso de service locators

Falla #4: La clase hace demasiado
Señales de advertencia:
  • Al describir lo que la clase hace usamos la palabra "y"
  • Sería complicado para un nuevo programador leer la clase y rápidamente comprenderla
  • La clase tiene campos que son usados solamente en algunos métodos
  • La clase tiene métodos static que solamente operan sobre los parámetros

Miško responde a los lectores que dejan sus comentarios, acá va una muestra interesante:

En la falla #3 mencionás que el "uso de registries" es una señal de advertencia. Pero la mayoría de las aplicaciones tienen algunos objetos que necesitan ser accedidos desde todas partes, o al menos en base a algún contexto. ¿Cómo manejaríamos tales objetos sin un registry? (...)


Y la respuesta:

(...) Registry, Context, ServiceLocator, o como quieras llamarlo, es un problema. En primer lugar, ¿cómo obtenés su referencia? ¿Variable global?

Las variables globales son problemáticas:
http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/

Los locators son problemáticos:
http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Y la solución es Inyección de Dependencias aun si es un objeto ampliamente necesitado:
http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
(...)

martes, 3 de febrero de 2009

Diseño orientado a objetos: The S.O.L.I.D. principles

Acá van los principios propuestos por el Tío Bob para un buen diseño orientado a objetos, en versión ultra condensada. No los sigo a rajatabla pero son una guía que conviene tener presente, como mínimo. En otro post voy a resumir las reglas de testeabilidad, que son un buen complemento a estos principios (y en parte se superponen).

Single Responsibility Principle (Principio de Responsabilidad Única)

Nunca debe haber más de un motivo por el cual modificar una clase.

Este principio se ve violado por todas partes. Un ejemplo típico es cuando un Servlet hace más de lo que debe. Ya de por sí trabajar directamente con servlets sin un framework que los esconda es una mala idea, pero cuando los usamos, debe ser solamente para dar acceso web a nuestra aplicación: levantar parámetros del request y elementos posteados, invocar las validaciones y servicios que corresponda (en otra capa) y manejar el response.

Open / Closed Principle (Principio Abierto / Cerrado)

Los elementos de software (clases, módulos, funciones, etc.) deben estar abiertos a la extensión, pero cerrados a la modificación.

En realidad, no podemos evitar completamente las modificaciones, pero el diseño puede tener en cuenta qué tipo de modificaciones contemplar, y permitir que cierto cambio de comportamiento se resuelva con nuevas implementaciones o subclases. De acá podemos derivar la regla general de "programar a interfaces", que las dependencias sean sobre abstracciones.

Liskov Substitution Principle (Principio de Sustitución de Liskov, o "Diseño por Contrato")

Los módulos que usen referencias a clases base deben poder utilizar objetos de subclases sin saberlo.

Las subclases deben seguir el comportamiento que se espera de la superclase. La superclase define un contrato. Si las subclases lo respetan, la superclase es sustituible por una subclase, y las subclases son intercambiables. Una regla relacionada con este principio es tratar de que el diseño permita a los usuarios del mismo prescindir del operador instanceof.

Interface Segregation Principle (Principio de Segregación de Interfaces)

Los clientes no deben verse obligados a depender de interfaces que no utilizan.

Las interfaces "gordas" producen acoplamiento entre clientes que deberían estar aislados. Un cliente no tiene por qué "ver" más de lo que necesita de una clase, entonces debería poder accederla a través de una interfaz particular. Por ejemplo, si tenemos una PavaElectrica, y la interfaz Pava define una dependencia con Agua, puede haber clientes para los cuales la PavaElectrica interesa sólo en tanto que ArtefactoElectrico. Y esos clientes deberían poder reutilizarse en proyectos donde haya otras implementaciones de ArtefactoElectrico pero donde no exista la definición de Agua.

Dependency Inversion Principle (Principio de Inversión de Dependencias, también conocido como "Inversión de Control")

Los módulos de alto nivel no deben depender de módulos de bajo nivel: ambos deben depender de abstracciones. Las abstracciones no deben depender de detalles: los detalles deben depender de las abstracciones.

El término "inversión" se debe a que este principio propone dar vuelta las dependencias con respecto a la tradición procedural: módulos de alto nivel que llaman a módulos de bajo nivel. En OOP creamos estas dependencias hardcodeadas cuando usamos el operador new. Cuando dependemos de abstracciones, las dependencias pueden ser inyectadas, en un módulo de inicialización o con un framework de inyección de dependencias.

viernes, 30 de enero de 2009

Lecciones funcionales para imperativos (2): Inmutabilidad

Se puede objetar que la definición de funciones puras en un lenguaje orientado a objetos sólo aplicaría a métodos static, de los que ponemos en clases de "utilitarios". Y los static no son nada representativos de lo que es el paradigma de objetos. Esta observación parece indicar que el paradigma funcional no se lleva bien con el de objetos, y que cualquier intento de fusión sería forzado y torpe.
Las clases más elementales de una aplicación típicamente definen getters y setters: el clásico "JavaBean". Los getters no son puros porque pueden retornar algo diferente cada vez. Los setters producen efectos colaterales al cambiar el estado del objeto.
Habíamos dicho que las funciones puras arrojan un resultado que depende solamente de los parámetros. Como los métodos de instancia se ejecutan en el contexto de un objeto, siempre tienen disponible su referencia, y podemos entender a esa referencia como un parámetro implícito. ¿Por qué, entonces, si un simple getter sólo depende del estado del parámetro implícito (el objeto al que pertenece), no tiene transparencia referencial?
El motivo es que la mutabilidad del objeto conspira contra este fin. Para que un getter tenga transparencia referencial, es necesario que el atributo retornado no tenga posibilidad de cambiar: que su valor inicial permanezca durante la vida del objeto. Por ende no debería existir el correspondiente setter:


class Person {
private String name;
private int age;

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String getName() { return this.name; }
public int getAge() { return this.age; }
}


De hecho, en la programación funcional pura no existen las variables. Todo valor es inmutable. En Java es fácil crear un primitivo inmutable, para eso utilizamos la palabra clave final. Pero para hacer inmutable un objeto, eso no alcanza: final garantiza que la referencia no apuntará a otro objeto, pero no impide que mute el estado del objeto referenciado. Para lograr esto tenemos que seguir el patrón del ejemplo de arriba.
Para quien haya programado siempre en lenguajes imperativos, la idea de trabajar sin mutabilidad puede parecer un sinsentido. Pero pensemos en algo de uso corriente: la clase java.lang.String es inmutable. En Java no podemos modificar un objeto String, y sin embargo podemos utilizar esta clase sin problemas.


String s = " test ";
s.trim();


En este ejemplo vemos un ingenuo intento de modificar la variable s aplicando el método trim(). Los que alguna vez cometimos este error, aprendimos que los métodos de String retornan una referencia a un nuevo objeto, el resultado del método. Si no guardamos la referencia, de nada sirvió invocar al método. Java no nos advierte de esta situación porque sus diseñadores siguieron el criterio de C y C++: se considera válido invocar a un método y descartar su resultado, porque se asume que se lo quiso llamar como procedimiento, y que sólo nos interesan los efectos colaterales.
Otro ejemplo interesante de uso intensivo de inmutabilidad es la librería Joda Time.
Entonces, resumiendo, lo que normalmente hacemos con mutabilidad, lo podemos lograr invocando funciones que producen un nuevo resultado que consiste en una transformación del valor original.

Un objeto inmutable es, por definición, thread-safe. La inmutabilidad nos da thread-safety en un sentido absoluto, sin depender de un mecanismo obtuso como el de la "sincronización".

Volviendo al ejemplo de la clase Person, ¿cómo definiríamos un método equivalente a modificar la edad de una persona?


public Person withAge(int newAge) { return new Person(this.name, newAge); }


Nada más simple.
El objetivo no es aplicar el paradigma funcional indiscriminadamente en un lenguaje como Java, porque no está en su naturaleza. Pero sí se puede tomar conceptos útiles y aplicarlos hasta donde sea razonable. Por ejemplo, podemos hacer una función con transparencia referencial cuya implementación usa variables:


public int sumChars(String s) {
int a = 0;
for(int i = 0; i < s.length(); i++)
{
a += s.charAt(i);
}
return a;
}


En un caso así no hay efectos colaterales, toda la mutabilidad está manejada en variables locales.