Mostrando entradas con la etiqueta Languages. Mostrar todas las entradas
Mostrando entradas con la etiqueta Languages. Mostrar todas las entradas

martes, febrero 21, 2012

Scala Implicits: simple examples

Durante la entrada anterior analizábamos los conceptos básicos de los implicits en Scala desde un punto de vista "teórico", dejando a un lado los ejemplos de código con el objetivo de no convertir el post en algo completamente inmanejable e incomprensible. A lo largo de la entrada que nos ocupa analizaremos diversos ejemplos de aplicación, describiendo con la mayor exactitud posible el mecanismo de funcionamiento de los implicits aquí descritos.

Como punto de partida realizaremos un sencillo ejemplo en el que veremos como realizar conversiones automáticas a un tipo determinado (el compilador las realizará por nosotros). Supongamos que disponemos de la siguiente definición de clase

class User (private val username:String)

y que deseamos obtener instancias de la clase anterior sin la necesidad de realizar llamadas del tipo 

val user:User = new User("migue")

El primer paso que debemos dar será llevar a cabo la definición del implicit correspondiente. En este caso la conversión deberá realizarse desde String hacia User. Para ello definimos algo como lo que sigue:

object UserImplicits {
    implicit def stringToUsername(user: String) = new User(user)
}

Nuestra siguiente tarea será hacer que el implicit anterior esté disponible en el ámbito donde lo queramos utilizar (una buena práctica suele ser realizar la definición de todos nuestros implicits en un singleton object llamado Preamble e importar dicho objeto al comienzo de nuestras clases):


import UserImplicits.stringToUsername
val user:User = "migue"

¿De verdad el código anterior compila? ¿Que está pasando? El proceso es "muy sencillo", el compilador detecta que hay un error de tipos puesto que no puede asignar una cadena a una variable de tipo User. Antes de declarar que existe un error ocasionado por una asignación de tipos incorrecta, el compilador busca si existe una conversión implicita disponible que le permita resolver el error encontrado. En este caso, el compilador buscará si existe un implicit que nos permita convertir una cadena de texto en un objeto de la clase User. Si revisamos la definición de nuestro primer implicit veremos que disponemos de una función que cumple los requisitos que el compilador está intentando satisfacer, por lo que este último, de manera interna, realizará algo similar a


val user:User = stringToUsername("migue")

El segundo ejemplo de uso de los implicits que vamos a tratar son las conversiones de objetos sobre los que se realiza la llamada de un método. Nuestro objetivo será añadir nuevos métodos a una clase externa que podría estar definida en una librería third-party sobre la que no tenemos ningún tipo de control.

Imaginemos la siguiente definición de clase en una librería externa (por sencillez esta clase estará definida en el propio archivo de código fuente junto al resto de ejemplos)


class ExternalClass {
def f1() = {
"f1"
}


def f2() = {
"f2"
}
}

en la que nos gustaría incluir el método def f3() = {"f3"}. Para llevar a cabo nuestra tarea construiremos una clase auxiliar en la que definiremos el método que deseamos incluir:



class MethodHelper {
def f3(): String = {
"f3"
}
}

e incorporamos un nuevo implicit


implicit def newMethodsToExternalClass(externalClass:ExternalClass) : MethodHelper = {new MethodHelper }



A continuación podremos escribir un código similar al que sigue:


import UserImplictis.newMethodsToExternalClass


println("Method f3() is added via an implicit conversion: " + externalClass.f3())


¿Qué está ocurriendo en esta ocasión? Durante el proceso de compilación, Scala detectará que existe un error puesto que el método f3() no forma parte de la definición de la clase ExternalClass. Antes de emitir un error, el compilador buscará una conversión implícita en la que se convierta el objecto receptor de la llamada del método f3() en un objeto que realmente posea dicho método. En nuestro ejemplo newMethodsToExternalClass es el elemento que nos permite que el código anterior compile correctamente. ¿Que está ocurriendo internamente? El compilador estará emitiendo un código similar al siguiente:

newMethodsToExternallClass(externalClass).f3()

Como último ejemplo para esta entrada, revisaremos cómo podemos hacer uso de parámetros implícitos en las llamadas a funciones. Incorporemos el siguiente método a la definición de la clase User

def encodePassword(password:String)(implicit encoder: Encoder) : String = {

encoder.encode(password)
}

Fijémonos que hemos marcado el segundo argumento de la función como implicit por lo que el compilador intentará completar las llamadas a la función añadiendo los parámetros necesarios. Definamos un encoder de ejemplo (que no realiza ningún tipo de operación útil) y utilizemos


implicit object IdentityEncoder extends Encoder {
  override def encode(password:String): String = password
}



import UserImplictis.IdentityEncoder


user2.encodePassword("foo")

Como podemos observar en el fragmento del código anterior en ningún momento estamos indicando el segundo parámetro de la función encodePassword sino que es el propio compilador el que está intentado incluir en la lista de parámetros alguno de los implictis disponibles de manera que la llamada de la función sea correcta.

Ha sido una entrada un poco larga pero he considerado que todos los ejemplos encajarían mucho mejor en una misma entrada de manera que pudieramos realizar un comparativa de los diferentes puntos de utilización de este poderoso mecanismo.

Importante: los snippets de código que aparecen a lo largo de esta entrada no están listos para ejecutarse en el REPL por lo que os aconsejo que, si quereis jugar con el código fuente, utilicéis aquel que está disponible aquí (realizaré el merge de esta rama sobre master tan pronto como me sea posible).

Hasta pronto!

Migue


lunes, febrero 20, 2012

Scala implicits (I)

Durante numerosas entradas hemos estado hablando del lenguaje de programación Scala, analizando algunas de sus principales características y/o la interacción con otros lenguajes: conceptos básicos, traits, parser combinators, combinando AspectJ y Scala, . . . Podéis encontrar todas las entradas relacionadas en el siguiente enlace: http://miguelinlas3.blogspot.com/search/label/Scala y un pequeño documento en el que se realiza una somera introducción al lenguaje: https://github.com/migue/blog-examples/tree/master/scala-intro

Durante las siguientes entradas me gustaría ahondar en algunas características más "avanzadas" del lenguaje como "type parametrization", "abstract members" o "implicitis" (estás últimas las abordaremos durante la entrada que nos ocupa).

El principal problema que se nos presenta cuando trabaja mos con una librería de terceros es la dificultad de extender y/o modificar el comportamiento de la misma. A lo largo de los diferentes lenguajes existentes podemos encontrar numerosas alternativas, cada una con sus ventajas e inconvenientes, como las open classes de Ruby o el ExpandoMetaclass de Groovy.

La respuesta de Scala al problema que nos ocupa son los implicits. El compilador intentará incluir en nuestro código fuente aquellos implicits que se encuentren disponibles con el objetivo de solventar cualquier "problema de tipos". De manera general, se rigen por las siguientes reglas:

  • Sólo estarán disponibles para el compilador aquellas definiciones que nosotros marquemos de manera explícita como implicit.
  • Los implicits deben estar disponibles en el ámbito de uso.
  • El compilador solamente intentará incluir un implicit de cada vez
  • El compilador no reemplazará código correcto.
  • ¿Dónde se utilizan los implicits?
    • Conversiones a un tipo determinado
    • Conversiones del objeto que recibe la llamada a un método
    • Parámetros de funciones
Hemos visto una pequeña introducción sobre la teoría de los implicits en Scala, las reglas que rigen el funcionamiento de los mismo y las aproximaciones que otros lenguajes utilizan. Puede que con este contenido la entrada se quede un poquito escueta pero he preferido dividirlo en dos entradas independientes por lo que en el próximo post realizaremos un ejemplo práctico y veremos las aplicaciones reales de esta potente (y a veces compleja) funcionalidad que el lenguaje nos brinda.

Hasta pronto!

Migue

lunes, noviembre 28, 2011

Algunos libros sobre Java y JVM

Durante estas últimas semanas he tenido la ocasión de terminar varios de los libros que tenía pendientes así como de realizar alguna nueva adquisición que, de momento, está encolada en mi lista de lectura.

Me gustaría aprovechar esta entrada para compartir con vosotros algunos de los libros anteriores que, bajo mi punto de vista, podrían resultar interesantes para tod@s aquell@s que os dediquéis, de algún modo, a trabajar con la plataforma Java (lenguaje y/o máquina virtual).

El primero de ellos es Java Performance from The Java Series. Escrito por Charlie Hunt, JVM performance lead engineer en Oracle, y  Binu John, senior performance engineer en Ning. Ha sido mi última adquisición y únicamente he podido leer los dos primeros capítulos pero creo que estamos ante uno de las lecturas obligatorias para tod@s aquell@s que se dedican y/o les gusta el mundo del rendimiento de aplicaciones sobre la JVM.

JVM Tuning, profiling, mediciones, herramientas, escritura de benchmarks, internals de la JVM, algoritmos de recolección de basura y tuneo de los mismos, gestión de la memoria,  . . .  son sólo algunas de las temáticas tratadas en este magnífico manuscrito.


Otro magnífica referencia  relativa al mundo Java: The well-grounded Java developer. Se trata de un early access por lo que sólo he podido leer los capítulos disponibles hasta el momento. Pensado para desarrolladores con unos sólidos conocimientos de Java el libro abarca un amplio espectro de temáticas como pueden ser:
  • Algunas de las novedades de Java 7
  • Nuevo mecanismo de IO y concurrencia
  • Classfiles y bytecode
  • Inyección de dependencias
  • Lenguajes alternativos en la JVM: Clojure, Groovy y Scala
  • Integración continua
  • . . .
En lineas generales creo que se trata de una lectura recomendada (a la espera de que se publique la segunda mitad del libro). Los capítulos pueden ser leidos de manera independiente, saltándose aquellos en los que ya se conoce de manera profunda la temática tratada en el mismo.

Un libro que había leido hace tiempo y que he vuelto a leer hace  unas semanas ha sido Java Concurrency in Practice. Poco puedo decir de este libro que no se haya dicho ya. Otra de las lecturas obligatorias para todos aquellos desarrolladores que trabajen con el lenguaje Java.

Ofrece una visión práctica de cómo se deben escribir programas escalables y seguros aprovechando la capacidad de las nuevas arquitecturas hardware.









Functional Programming for Java Developers. Escrito por Dean Wampler. Es un libro en el que se introducen los conceptos básicos de la programación funcional (que está "renaciendo" gracias a lenguajes como Scala o Clojure, además de sus beneficios a la hora de escribir programas concurrentes entre otras muchas cosas).

Es un libro muy cortito aunque personalmente no me ha entusiasmado demasiado. Si no tenéis ninguna experiencia en programación funcional puede ser un buen punto de partida. No se cubren mónadas, laziness ni combinators.

miércoles, marzo 30, 2011

Parser Combinators: un poco de teoría

Puede que en algunas ocasiones os hayais tenido que enfrentar con la necesidad de escribir un pequeño lenguaje que realice una tarea muy concreta (profundizaremos en el tema de los DSLs en un post futuro): como, por ejemplo, procesar determinados archivos de configuración de vuestra aplicación o la definición de interfaces de usuario de manera sencilla.

Independientemente de las razones por las que estamos desarrollando este componente, necesitaremos un parser que nos ayude a transformar el lenguaje de entrada en una estructura de datos que nuestro programa pueda comprender y procesar. Algunas de las alternativas que se nos plantean son:
  • Escribir nuestro propio parser (conllevaría escribir también el analizador léxico). Si no somos expertos en la materia estaremos enfrentándonos a una tarea relativamente complicada.
  • Utilizar herramientas para la generación de parsers como Antlr,Bison o JavaCC entre otras muchas. En este caso la dificultad estriba en la necesidad de aprender a manejar una nueva herramienta/lenguaje e integrarlo en nuestro desarrollo y ecosistema.
Durante esta entrada, y posiblemente la siguiente, vamos a presentar un enfoque alternativo a las dos opciones anteriores. En lugar de utilizar un DSL externo como podría ser el ofrecido por Antlr, vamos a utilizar un DSL interno. Dicho DSL estará formado por parser combinators (funciones y operadores definidos en Scala que servirán como base para la construcción de nuestros futuros parsers).

Siendo originales :), imaginemos que deseamos cosntruir un parser de expresiones aritméticas de números enteros. En primer lugar, definamos la gramática de nuestro lenguaje:

expr  ::= term {"+" term | "-" term}. 
term  ::= factor {"*" factor | "/" factor}.
factor  ::=  integer | "(" expr ")".

El fragmento de código anterior representa una gramática libre de contexto (no vamos a profundizar en este tema porque tendríamos que escribir miles de posts) que modela nuestro lenguaje de expresiones aritméticas de números enteros. ¿Y ahora?

Una vez definida la gramática anterior hemos llevado a cabo la tarea más complicada de todas. Si utilizais los parser combinators ofrecidos por Scala tendremos casi todo el trabajo sucio realizado. A modo de ejemplo:

import scala.util.parsing.combinator._

class IntegerArithmetics extends JavaTokenParsers {
   def expr: Parser[Any] = term~rep("+"~term | "-"~term)
   def term: Parser[Any] = factor~rep("*"~factor | "/"~factor)
   def factor: Parser[Any] = integer | "("~expr~")"
}

Si comparamos el código Scala con la definición en notación EBNF de nuestra gramática observaremos que podríamos inferir nuestro código fuente Scala sin más que realizar una serie de reemplazos en nuestra notación EBNF:
  1. Cada regla se convierte en un método por lo que tendremos que prefijarlas con def.
  2. El tipo de retorno de cada uno de los métodos anteriores es Parser[Any] (veremos en la siguiente entrada que significa esto) por lo que tendremos que cambiar el símbolo "::=" por ":Parser[Any] ="
  3. Insertar el símbolo ~ entre todos los elementos de cada una de las reglas (en la notación EBNF esto es implícito)
  4. La repetición se refleja mediante el uso de rep(...) en lugar de {...}
  5. El punto al final de cada regla no es necesario (podríamos poner ; si lo deseamos)

Esto no ha sido más que una toma de contacto con el mundo de los parser combinators en Scala. En la siguiente entrada descubriremos cómo realizar construcciones más complejas, formatear la salida de manera que podamos construir las estructuras de datos requeridas para nuestro procesamiento o ejecutar nuestros parsers. 

Para todo ello diseñaremos y construiremos un pequeño parser que nos permita analizar el bytecode de la máquina virtual una vez desemsamblado (para los más inquietos javap -v ClassFile (sin .class))