Eso no es en la mayoría de los lenguajes?

En java pasa eso al menos .

(28-08-2013 15:24)gonnza escribió:  

Cita:Objects of the same type will have access to each others private and protected members even though they are not the same instances. This is because the implementation specific details are already known when inside those objects.

a ver

 using System;



public class Prueba

{

    private string variable = "soy privado";



   public void imprimoPrivado(Prueba prueba)

  {

     Console.WriteLine(prueba.variable);

   }

}





public class program

{

   public static void Main()

   {

      Prueba v1 = new Prueba();

      Prueba v2 = new Prueba();

      v1.imprimoPrivado(v2);

   }

}

---

ah, que horror


nose, no me pareceria algo logico, el private field deberia ser privado por instancia, no por clase D:

Por algo es privado...

tirando asi comentarios sueltos no termino de entender tu postura.

No se, yo tenia entendido que los objetos se comunicaban entre si por la interfaz publica que ofrecen. Ahora, si todos los lenguajes oop permiten lo mismo ni idea, pero al menos php java y C# si. Yo cuando lei que php lo hacia parecia algo "diferencial" (de ahi fui al manual) y me sorprendio bastante porque bueno, no lo esperaba. Como digo, los objetos ofrecen interfaz con la cual le podes mandar mje, y si tienen algo con acceso privado no deberia ser visible por nadie, pero bueno.. el encapsulamiento es a nivel clase y no instancia se ve.

Que algun purista de objetos me cante la posta

Lo que digo es justamente que, siendo un miembro privado, no le veo el sentido en que otras instancias tengan acceso a esto. Es como vos bien dijiste, toda clase tiene su interfaz (pública) para interactuar con otros objetos. Que un miembro sea privado (a mi entender) implica que es accesible solamente por la instancia. Entiendo que en casi todos los lenguajes OO esto es así y entiendo que debería ser así. No le veo sentido a algo privado accesible por otra instancia.
Pero bue, cada cual tiene sus preferencias!

Off-topic:

ah, es que por tu facepalm pense que era hacia mi por pensar eso

(26-03-2013 10:58)Jarry escribió:  php tambien

Es cierto. La ausencia de evidencia no es evidencia de ausencia.
Que yo no conozca una sola persona que haya logrado hacer andar/use el zend debugger no significa que no funcione.
Igual, creo recordar que hasta vos me reconociste que el debugger de .NET es mejor.

Cita:no parlo LINQ, pero busca PDO

.

Oh, harry, me engañaste, me mentiste.... (8)....

PDO no es ni remotamente parecido a LINQ.
Vos no podes agarrar una coleccion cualquiera y tirarle queries sin abstraerte de si viene de una db o no.

Cita:- Namespaces
php tambien tiene!

Cierto, tienen desde el 2009.
I have to give credit where credit is due.

Cita:tambien. http://php.net/manual/en/book.image.php

¿Con GD? ¿Really?
PD: Ya estuve ahi. Te volves loco tratando de manejar las cosas con imagecopyresampled.
Termine con una librería que encontre por ahí que me abstraia del tabajo + algo de codigo objetoso que paliaba un poco el tema pero aun asi el codigo era asqueroso.

Ahora te busco el codigo en .NET (no lo tengo aca) pero era asi de corto.

Cita:meh, depende de la configuracion

Te doy la razon en que el VS2012 no es lo mejor en terminos de color (aparentemente se fueron por lo "retro" y les quedo horrible).

Cita:- Podés iniciar una aplicacion web en dos clicks con una página de ejemplo que despues podes usar de ejemplo o volar a la mierda.
no le veo lo copado a esto

Ok. No tenés que editar el vhosst-conf cada vez que te pasan un nuevo proyecto. Le das click al play y lo tenés corriendo.

Cita:- El codigo es mas entendible al no tener $ delante de cada variable
ah? really?

Tiene sus ventajas, no lo niego, no tenes que encriptar el téxto de tu código, ya que viene asi por default.

¿Realmente te parece que es igual de legible el codigo en C# que el escrito en PHP?
¿Really?

Ya vuelvo, me pasaron un programa en PHP. Descrifrarlo es crucial.
Voy a estar en la cámara del entendimiento.

Cita:dale! dame las razones de verdad por las cuales php apesta. yo ya se dos o tres que son desventajas sin dudarlo, pero si te las dijera seria demasiado facil

Seria demasiado fácil.

Podría empezar con los mensajes de error crípticos (aunque reconozco que para los fanaticos del lenguaje encontrarse con un "TPAAYIM:NEKUNDOTAYIM" les debe parecer algo genial, lo podrían reemplazar por un "missing colon at line 257").

O que no tengas que meter constructores personalizados adentro de una función que se llama __construct() (!).
( http://php.net/manual/en/language.oop5.decon.php )

Cita:Decime cómo y de dónde sacaste ese "cálculo". Lo mas factible es que lo hayas hecho a espaldas y desde algún lugar donde vos te encuentres más cómodo pero ese "se calcula" no se calcula ni esta demostrado en la práctica!!

Ehh....Por supuesto que no lo calcule. Asumi que, como la mayoria de los programadores actuales (*) commitear teniendo una herramienta que te permite analizar que archivos commiteaste, hacer un diff con dos clicks y marcando las cosas en color y por supuesto hacer reemplazo globales en todos los archivos de texto que tengas abiertos son herramientas útiles ya que se usan todos los días.

Off-topic:

* El paper con los datos lo saco el mes que viene, stay tuned.(**)
** Lo de arriba era joda.

(28-08-2013 15:24)gonnza escribió:  http://theserverpages.com/php/manual/en/...bility.php

Cita:Objects of the same type will have access to each others private and protected members even though they are not the same instances. This is because the implementation specific details are already known when inside those objects.

jaja php siempre me hace reir

php no tiene funciones de manejo de threads


lo ironico es que estoy programando en php y de a poco le voy tomando cariño

igual admito que sin un fwk, progamar php plano se vuelve un poquitin doloroso

(28-08-2013 22:45)gonnza escribió:  igual admito que sin un fwk, progamar php plano se vuelve un poquitin doloroso

+1, pero ojo con el recíproco: si tenés que hacer algo bien simple, lo sacás en 2 patadas.

Off-topic:

Cómo se te ocurre que te voy a mandar un facepalm a vos, zonzo!

Para una opinión de purista de Objetos, tendría que citar esa frase de Kay que dice algo como <<Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind>>.

Kay dijo "los atributos son privados, toda la relación que hay es a través de mensajes". De ahí en adelante, todos se cagaron en eso e hicieron lo que hicieron.

Lo vuelvo a leer y me rio. Son unos carniceros los de php

(29-08-2013 02:55)Desert69 escribió:  Para una opinión de purista de Objetos, tendría que citar esa frase de Kay que dice algo como <<Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind>>.

Kay dijo "los atributos son privados, toda la relación que hay es a través de mensajes". De ahí en adelante, todos se cagaron en eso e hicieron lo que hicieron.

ah osea estuve bien digamos (Siendo purista)

el tema es que como (aparentemente) varios lenguajes hicieron lo mismo, pierde "peso"

En smalltalk todo metodo no es público?

Tal vez el problema está en pensar que los atributos pueden ser otra cosa aparte de privados... (además que acceder a un atributo privado de otro objeto, por más que sea de tu misma clase, definitivamente es un "estoy haciendo algo mal", mas allá de si el lenguaje te deja hacerlo o no).