No entiendo que quieres decir con "no-tan-purista". En Ruby no tienes funciones porque todo, absolutamente todo, son objetos. Así que, lógicamente, sólo hay métodos.
No lo digo por eso y no me parece mal la aproximación de Ruby, sólo justificaba en el párrafo anterior por qué no se hace así en Python si, a fin de cuentas, sería cortar y pegar unas cuantas líneas en el archivo de la gramática y explicaba en éste el caso de Ruby.
Digo que Ruby no es el más purista de los lenguajes OO porque en él NO TODO es un objeto: por ejemplo no los son las estructuras de control del lenguaje. En Smalltalk sí.
Bien pensado, en Python si no nos ponemos quisquillosos, también se puede decir que "todo", o casi, es un objeto.
Supongo que lo que pasa que en Python el concepto gordo no es el de clase sino el de espacio de nombres, como todo el mundo sabe. A los objetos se hace por su nombre consultando el espacio de nombres en el que estemos (un diccionario que mapea nombres con objetos, entendiendo por objeto cualquier cosa: funciones, tipos básicos, clases, etc), las clases, los módulos, las funciones... Definen nuevos espacios de nombres y las instancias guardan sus propios valores en ellos.
Lo bueno es que así Python es coherente. A partir de los espacios de nombres monta todo: módulos, funciones, clases, objetos, etc. Y todo se comporta de la misma manera. Lo malo es que, por mantenerlo simple no hace excepciones para "mejorar" la sintaxis orientada a objetos. Pero vamos, esto es a "bajo nivel". Tú lo que ves en la superficie es que "todo" es un objeto y listo :-).
[Sobre C++] Es lógico que no se genere código especial: en teoría ya se ha comprobado que no se accede a atributos privados durante la compilación.
Lógico si no le pides más que sea un mecanismo para evitar despistes. Si quieres, desde el mismo programa que se ha verificado se puede acceder a ellos leyendo de la memoria que ocupa el objeto. Si puedes inyectar código de alguna forma también. O puedes extender esas clases con acceso a sus atributos privados simplemente modificando las cabeceras y enlazando con el código objeto verificado por el compilador antes.
Yo no veo la diferencia (salvando las distancias y el compilador) entre esto y lo que hace Python. En ambos puedes acceder a los datos privados pero tienes que hacerlo "a posta" :-), con todas las consecuencias.
En el caso de Ruby [para acceder a lo privado] estás declarando un nuevo método desde el cuál acceder al atributo privado.
Conceptualmente, estás modificando la clase.
Conceptualmente los atributos privados de Python lo son :-): lo que falla es la práctica, y en Ruby igual.
Además, no sé exactamente como va pero me extrañaría que el soporte para depuración estuviera incluido directamente en el intérprete de Ruby, así que posiblemente exista un "escape" similar al de Python, más simple que lo que yo propongo, para que pueda inspeccionar las variables un depurador externo.
En fin, que Python es un lenguaje orientado a objetos como el que más porque soporta encapsulación, herencia y polimorfismo, y su encapsulación no es menos encapsulación porque haya trucos (no recomendados) para saltársela, al menos conceptualmente hablado :-).
[ Padre ]
|