Hola,

Me surgen muchas dudas con este asunto. Dudas que no van a ningún sitio, avisados quedáis. Al cabo de darle algunas vueltas me pregunto, ¿puede un objeto ser "nil"? Y me respondo: tal vez sí, cuando busquemos un objeto que puede o no haber sido creado, pero, no, si de lo que se trata es de crear dicho objeto. Es decir, yo veo el siguiente código "válido" y de hecho he escrito mucho código de esta forma:

Código Delphi [-]
var
  module : TMyModule;
begin
  module := MyModules.GetModule( 123 );  

  if module <> nil then
  begin
    // Module is a valid object for us
  end
  else
  begin
    // We can't found a module with ID 123
  end;
end;

En el código de arriba, puesto que no estamos creando un objeto sino tratando de asignar uno (posiblemente) existente, creo que el "nil" tiene toda la lógica, puesto que el método "GetModule" retornará "nil" si no puede encontrar un objeto o el objeto mismo.

Ahora bien, si de lo que se trata es de saber si un objeto se puede crear, correctamente, en base a ciertos argumentos, entonces yo escribiría un código similar a este:

Código Delphi [-]
var
  params : string;
  module : TMyModule;
begin
  params := 'My params';

  module := TModule.Create( params );

  if module.HasValidParams() then
  begin
    // We have a valid object here, with the right params
  end
  else
  begin
    // We have a valid object here, but with wrong params
  end;
end;

¿Se entiende por dónde voy? Nosotros pasamos los parámetros conque contemos (tal vez sean válidos, tal vez no lo sean) al constructor de nuestro objeto, y, este, por ejemplo, proporciona un método "HasValidParams", que, podremos usar para comprobar si el objeto de hecho se ha creado en condiciones... con los parámetros correctos.

De esta forma nos olvidamos del "nil", nos olvidamos con un método de clase que nos retorne una instancia del objeto mediante ciertos parámetros (¿podré usar el constructor sin parámetros o los necesitaré también?) y es el propio objeto, conocedor de los parámetros que necesita, quien nos dirá si está listo para usarse o no.

¿Cómo lo veis? ;)

Muy bien dicho David, has ido a lo que yo quería hacer llamar la atención. Como tu has dicho:

Y yo por algo había comentado antes:

Al, es primordial entender ¿que significa para ti que el objeto sea nil? ¿Tiene algún propósito?

Porque como lo ha dejado en claro en el ejemplo David, si la idea es garantizar o evaluar si hay cierta consistencia, quien tiene la información para hacerlo es el creador o el objeto en si mismo. Esto conduce a que para hacer algo entonces se puede disponer de un método que lo compruebe, y ahora si ya en base a estos resultados decidir que o no hacer.

Y como dije antes, si nil no es una opción a considerar sino una situación fuera de lo esperado los lineamientos de la OO indican que lo sano es elevar excepción.

Saludos,

Yo apunté también lo propio (lo siento Delphius, no leí tus anteriores mensaje), pero, ¿serviría de algo lanzar la excepción en el constructor del objeto? Me refiero a si tiene sentido en el contexto en que nuestro amigo Al trabaja. Además no me queda muy claro el uso de excepciones tal que así:

Código Delphi [-]
try
  obj := TMyObject.Create();
except
  on E : Exception do
  begin
    // Manejamos la excepción, pero,...
  end;

  // ¿qué pasa con el código situado aquí debajo?

end;

Ahora mismo mis dudas es si la discusión estilo narco / mafia que se desarrolla justo afuera de mi ventana tendrá repercusiones en nuestra vida. Y si lograremos encontrar un sitio más económico (y seguro) antes de que la renta venza. :(

:)

--------------

Volviendo al tema, es algo que implementaré en un par de clases de GH Freebrary. Cuando esté listo lo subiré y ya me dirán si estoy haciendo bien las cosas. :o

Descarto los nombres que llevan la palabra Create o Instantiate porque son demasiado "fuertes" en el sentido de que parece que forzosamente se creará un objeto. Y lo del AndNil / OrNil los veo como recursos léxicos baratos; lo identificadores debieran llevar lo menos posible preposiciones, conjunciones y similares (hago uso de ellos en contadas ocasiones).

Saludos.

Pues, por eso dije que lo sano según OO sería arrojar una excepción. Pero el contexto/uso/modo de esta problemática como que me rompe los moldes y no ando seguro.
Respecto al código de ejemplo, me hago la misma pregunta que tu. ¿Que pasa allí abajo? ;)

Al, no es que esté mal o bien... sino que es diferente. Si no es mucha molestia, ¿Podrías concretar un poco más? Y como dije antes... me gustaría saber que significaría un resultado nil. Creo que ello ayudaría a entender mejor el panorama y ver alternativas.

Aunque admito que mi ración de neuronas despiertas del día son escasas... tengo un diagrama de estados para una clase que acaparó demasiados recursos y mi cerebro no ha logrado restablecer la electricidad :o :p

Saludos,