Cita:Indeed, the Smalltalk way is to put private methods in the 'private' category. This indicates that you shouldn't use these methods, but of course doesn't enforce this.
This is by design - it's a feature, not a bug. Smalltalk was designed from the beginning precisely to be an open system.
Some advantages:
If I simply have to - maybe the library designer didn't forsee a need to expose some particular thing I simply have to have - I can still call those private methods. Obviously, this isn't something one does lightly: rather, judiciously, cautiously, knowing that it's a tactical solution.
Language simplicity.
(As per Alexandre Jasmin's comment) Smalltalk makes no distinction between what you, the programmer, can do and what the language/environment can do. That means that Smalltalk-the-image exposes all the things needed for you to build your own inspectors/debuggers/whatever without having to supply special tools using we-can-do-this-but-you-can't techniques.
ammm... En todos los lenguajes que toque, podes acceder a metodos privados desde cualquier lado... En algunos en mas simple, en otros mas complicados. En algunos lo haces de forma linda, en otros tenes que hacer chanchullos...
Al fin de cuentas, una clase, es memoria, y podes leer memoria de donde vos quieras...
Cita:ammm... En todos los lenguajes que toque, podes acceder a metodos privados desde cualquier lado... En algunos en mas simple, en otros mas complicados. En algunos lo haces de forma linda, en otros tenes que hacer chanchullos...
Hablamos de accederlo de manera normal, como si fuese un metodo más.
La idea de Smalltalk es centrarse en el encapsulamiento. Entonces, pone una barrera MUY clara: el estado interno del objeto es *interno*. Desde afuera *no lo ves*, porque *no te interesa*. A vos sólo te interesa qué es lo que el objeto puede ofrecerte/contestarte/qué podés pedirle.
El poder de objeto-mensaje es ese: yo te pido cosas mandándote un mensaje, y espero que me contestes o hagas algo que estipulamos en el contrato de ese mensaje. Después, *vos hacé lo que quieras*. Si tenés estado interno para manejar esa situación, si tenés un método llamado como ese mensaje, o si el Papa está en el Vaticano todo el día tipeando qué objeto devolver a cada mensaje que se manda, a mí me importa tres carajos. Lo importante es que yo te mandé un mensaje, y entonces vos sabés qué es lo que yo quiero, y vos me cumplís.
Poder acceder a una property de un objeto es una cagada, porque implica que *esa property existe*. El chiste de los getters y setters no es vender más LoC al cliente como hacen los forros de Java, sino que si mañana tengo ganas de meterme mi variable en el ojete y reemplazarla por cualquier otra cosa, yo actualizo el getter/setter y listo el pollo: vos no te enteraste del cambio.
Es por el mismo motivo que en general en las interfaces en Java se definen muchos getters pero no tanto setter: podrías tener implementaciones que *no guarden estado*, por lo que puede no tener sentido decir que *todos* los objetos que implementen esa interface van a tener un setter.
El mayor problema es que 40 años después sigamos sin tener en claro estas cosas, y sigan existiendo lenguajes de mierda que hacen eso otro que nombramos por ahí.
El que quiera invertir media horita de su vida en un mindblow, mirense este video:
Salute!
PD: lo de "reflection no vale" es con criterio.
Reflection es metaprogramación. Metaprogramación vale siempre y cuando estemos metaprogramando. Cuando estás escribiendo un programa, estás metaprogramando (estás usando programas que te ayudan a crear un programa). Ahora, cuando tu programa está corriendo, ya no hay metaprogramación: tu programa está haciendo cosas "de usuario". Si ahí necesitás recurrir a la metaprogramación, o estás haciendo las cosas como el culo, o estás haciendo las cosas como el culo porque tus herramientas te dejaron a pata.
Off-topic:
Última y dejo de joder: "instancia" es una traducción de mierda, como "librería" y tantas otras. El sentido de instance es el de especimen, ejemplar. Estúpidos gallegos.
Aunque creo que estamos a años luz de que alguien pretenda cambiar esto (todavía seguimos diciendo "librería", qué queré...)
Cita:Symfony is a PHP framework, ie server-side application framework. It doesn't provide client-side validation unless you use HTML5 one with required attribute and other email type for input (that is still not very well implemented in browsers).
Cuando dije "reflection no vale", me referia a que uno no puede decir "que lenguaje de mierda, te deja acceder a metodos privados" si la unica forma de acceder a los mismos es no-usando el mecanismo normal de acceso a los metodos .
Seria como decir "que verga haskell, se hace el funcional pero podes codear como si fuese imperativo". Y si, se puede. Pero normalmente no deberias de tenerlas en mente, incluso hace que te cueste mas hacerlo imperativo que funcional (ver bucles)
Cita:El chiste de los getters y setters no es vender más LoC al cliente como hacen los forros de Java, sino que si mañana tengo ganas de meterme mi variable en el ojete y reemplazarla por cualquier otra cosa, yo actualizo el getter/setter y listo el pollo: vos no te enteraste del cambio.
En las consultoras en las que estuve normalmente se vende por funcionalidades, no se que tipo de consultora te cobraria por lineas
devuelta. capaz que no leyeron el primer post. hay cosas que bardear en serio en php(de verdad, hay dos o tres cosas jodidas muy feo), las boludeces que dicen no.
no lo voy a recorrer entero como ya hice. esto viene de un boludo que quiere usar php como si fuera python. quisiera verlo en c# con esa actitud a ver como le va.
(04-03-2015 22:03)Jarry escribió: [ -> ]devuelta. capaz que no leyeron el primer post. hay cosas que bardear en serio en php(de verdad, hay dos o tres cosas jodidas muy feo), las boludeces que dicen no.
Cita:no lo voy a recorrer entero como ya hice. esto viene de un boludo que quiere usar php como si fuera python. quisiera verlo en c# con esa actitud a ver como le va.
Quiere usar PHP como si fuera un lenguaje de verdad.
Estamos en el 2014 y el soporte para unicode nativo no existe, a diferencia de todos los otros lenguajes del nicho. No tiene import ni uses y el manejador de paquetes es casi inusable en Windows, debido a que tenés que compilar todo de fuente:
Con lo cual la mayoría de la gente usa los defaults, como GD que es una libreria con la que es una patada en los huevos laburar.
Si el tipo migra de Python a C#, esas cosas existen igual. Querer usar PHP como si fuera Python sería pedir que los tipos implementen sum(), map(), o lambda().
(04-03-2015 22:03)Jarry escribió: [ -> ]devuelta, cada lenguaje se adapta mejor a diferentes casos.
Pone las ventajas de usar PHP entonces. Si se adapta a algun caso mejor que otro lenguaje de su nicho debe tener ventajas que lo hacen mejor.
POR LO MENOS YOOO no creo que este tan mal xD.gif ";)")