FWN/Issue275

= Fedora Weekly News Issue 275 =

Welcome to Fedora Weekly News Issue 275 for the two weeks ending May 18, 2011. What follows are some highlights from this issue.

FWN is back after a hiatus last week! In announcements from the Fedora Project, important details on changes to requirements for all Fedora contributors, as well as country requirements for steering committee members. In development announcements, a couple outage announcements as well as the Fedora 15 final change deadline details, and later details of Fedora 15's Gold release status. In Fedora In the News, six articles from the trade press and blogs this week around Fedora 15, Virtualbox, and work on packaging Unity for Fedora 15. The Ambassador team this week announced new Ambassadors for the Netherlands and Israel, a summary of traffic from the Ambassador and FAmSCo lists and a couple event reports from Flisol in South America. In Quality Assurance news, reports on the latest Test Day on Cloud services, details on Fedora 15 validation and preparation, and report on recent AutoQA news. Security Advisories brings us current with security-related package releases for Fedora 13, 14 and 15, and Fedora LATAM is back with another Spanish-language tutorial on Ruby. Enjoy FWN 275!

An audio version of some issues of FWN - FAWN - are available! You can listen to existing issues on the Internet Archive. If anyone is interested in helping spread the load of FAWN production, please contact us!

If you are interested in contributing to Fedora Weekly News, please see our 'join' page. We welcome reader feedback: news@lists.fedoraproject.org

FWN Editorial Team: Pascal Calarco, Adam Williamson

De forma alternativa puede simplemente listar los métodos en dichas funciones.

Ejemplo private
El ejemplo abajo muestra un esqueleto para proteger un método peligroso de alteración del estado del objeto por medio del uso de otro método intermediario que se supone asegura el acceso, esto ayuda a mantener el código separado pero simple, uno asegura por ejemplo las credenciales, el otro ajusta el estado del objeto.

Ejemplo protected
Por definición este control de acceso limita el acceso a la familia, objetos de la misma clase, y objetos de clases derivadas de la clase que define el método protegido. Abajo un ejemplo simple para comparar manzanas con manzanas, no con peras.

Al intentar hacer la comparación entre manzana y pera, se invoca pera.peso en el contexto de las manzanas, y ya que el método está protegido, entonces da el error.

Ahora bien, esta idea de uso para protected en realidad está en franco desuso por muchos ya que va en contra de la flexibilidad y dinamismo natural de Ruby y del concepto de Duck Typing que explicaremos a continuación.

Duck Typing
En Ruby no declaramos tipos de variables o tipos para los métodos, todo es simplemente alguna encarnación, un objeto de una clase, y las clases no son tipos. Si deseamos programar con la filosofía Duck Typing lo único que necesita recordar es que el "tipo" de objeto está determinado por lo que puede hacer, no por su clase.

En la práctica esto significa que hay pocas pruebas de valores de objeto. Por ejemplo digamos que estamos programando un método para agregar información de dos objetos de cierta clase y obtener un resultado String. Los programadores con conocmientos de C# o Java estarían tentados a hacer algo como lo siguiente:

Si abraza la filosofía Duck Typing de Ruby podrá escribir este método de una forma mucho más simple.

Usted no necesita verificar el tipo de los argumentos en tanto que se soporte el método << en obj1 simplemente todo funcionará bien. Si no es así, se lanzará una excepción de todas maneras, el mismo resultado de que si usted hubiera implementado la verificación. Pero de pronto su método es mucho más flexible, puede pasarle otros objetos no necesariamente String, tal vez un Fixnum.

¿Qué pasa si obj1 no soporta el método << entonces?

Obtenemos una excepción NoMethodError para el método << para la clase Float en este ejemplo. Una forma de prevenir posible es usar el método respond_to?:

Pero nuevamente esto es más código que mantener y hay que evaluar si realmente quiere tomar ese trabajo ya que igualmente podría manejar las excepciones más arriba.

Si ahora pasa un Array como obj2 obtendrá un error de tipo ya que Array no es un String pero si podemos invocar el método to_s para obtener una representación razonable. En última instancia lo que queremos es que nuestro método si nos devuelva un String.

Esto nos lleva a una nueva versión del método anexar, usando to_s para "convertir" los objetos en String, ahora ya tampoco necesitamos la verificación respond_to? ya que String responde a <<. Tal vez ahora lo que necesita es validar es que tengan una representación en String, es decir, que respondan a to_s.

El código de prueba puede llevarle nuevamente a situaciones indeseables. ¿Soporta obj1 << pero no to_s? Es mejor lidiar con las excepciones que ponerse a probar los tipos y/o los métodos a los que responde. Con esta nueva versión, podemos por ejemplo pasarle dos arreglos, mejor dicho, cualquier par de objetos que tenga una representación String (to_s) y concatenarlos y obtener una salida en String.

Ahora veamos nuestro método en acción con varios objetos involucrados:

De lo único que debe preocuparse en su clase particular es que soporte to_s para tomar ventaja de nuestro método, si no fallará con una excepción. Veamos:

Por supuesto puede sobrescribir el método to_s heredado de Object.