Saber si un objeto esta instanciado

Hola, Carlos!

Para mi lo mejor sería tener solo un tipo String.

Sí, eso suena totalmente razonable...

Claro, el significado del == depende entonces de los tipos/clases

y eso embrolla el lenguaje. Determinar la igualdad de valores
en distintas variables es un concepto muy básico en programación
y debería ser consistente.

También tiene toda la lógica del mundo lo que dices, pero por otra
parte... ¿no os "repateaba" tener que escribir

if (s2.equals(s1)) ...

para comparar dos cadenas en Java? A mí sí...

Y lo q es peor, q sin darte cuenta puedes decir

if (s2 == s1)

y estarías comparando las referencias cuando lo que querías era
comparar los valores... Claro, el compilador podría dar una advertencia,
etc.

Saludos - Octavio

Bueno, yo me imagino un lenguaje donde solo haya un 'tipo' de
tipos, valga la redundancia; que se comporten de manera uniforme.
Los problemas de rendimiento no deberían ser solucionados en el
diseño de un lenguaje sino en la implementación para quitar de
en medio esta carga administrativa a los programadores.
Por ejemplo en C# no tendría porque haber una diferenciación
entre tipos primitivos y clases en el lenguaje. Sí podría
la implementación (compilador) 'ser consciente' de algunos tipos
y sus operaciones y optimizar; lo que se le impone ahora al
programador al tener que aprender un lenguaje más complicado.
El programador no tendría por qué ser consciente de ello.

No estás pidiendo nada nuevo. No solo hay lenguajes que no
hacen diferencias entre tipos de datos escalares (o simples) y
compuestos, también están aquellos dónde los nombres no tienen
que estar asociados a un tipo. Pero una implementación eficiente
no es sencilla.

Todo el mundo está de acuerdo que cuanto menos tenga que
escribir el programador, mejor. Desgraciadamente, todavía estamos
en pañales. Por suerte, esto es ciencia, y seguramente en los
próximos años veremos muchísimas mejoras especialmente
dado los avances en inferencia de tipos.

En el caso de C#-CLI hubo decisiones que evidentemente se han
tomado buscando la mejor conveniencia para acortar distancias
respecto a Java-JVM (que le llevaba 10 años)

Mejor aun, me imagino un sistema de tipos común y externo a
todos los componentes que puedan formar parte de un sistema.
Así si yo digo por ejemplo en una base de datos que Nombre
es un String no tengo por que volver a decirlo en las
aplicaciones que usan ese dato; y si lo tengo que decir,
por lo menos que sea el mismo tipo String.
Lo que es un String estaría definido fuera del lenguaje
de programación, fuera del sgbd y fuera de cualquier otro
componente que pueda formar parte del sistema. Esto sería
especialmente importante para todos aquellos datos que pasan
de unos componentes a otros por medio de alguna interfaz.

Bueno.. basta de visiones de futuro :)



>http://www.ifi.unizh.ch/richter/Cla...3_small...

> Y en los lenguajes de Hejlsberg, ya desde Delphi 2 (1996, cuando Java era
> aún "de juguete")
> se añadieron las cadenas por referencia con recolección automática...

Tampoco es que Java haya inventado todo esto. En realidad no hay
nada nuevo en Java. Lo más positivo, creo yo, es que ha popularizado
(por fin!) la recolección automática, de la que ya había otras
implementaciones ya hacía muchos años.
Lo que parece triste es que una idea ya lleva ahí *casi 50 años!*;
de repente aparecen implementaciones por todos los lados solo porque
unos imitan a otros y no porque estaban muy preocupados con el
hecho de que los programadores llevan años y años gestionando
memoria 'a mano'.

Opino distinto. No creo que sea un tema de moda o de imitaciones.
Las necesidades son diferentes hoy día. No se programa igual que
antes,
no se usan los mismos paradigmas, la relación de costes entre
hardware y software no es igual que hace 30 años ni la demanda de
productividad tampoco es la misma (hace 20 años era normal que los
proyectos se midieran en años/hombre y hoy día la gran mayoría
apenas duran unos pocos meses.)

-H.

Hola Rafael

Una opinión personal sobre el tema,

net framework es muy grande, fijate que ya no hablo de c# ( en net el
lenguaje es anecdotico, el ejemplo que mande se puede escribir en vb.net, c#
o lo que gustes ).

Para desarrollar en net, lo mismo en otras plataformas, java por ejemplo,
hay que manejar muchos conceptos.

1 - Plataforma ( net framework en nuestro caso, JDK en el de java )
2 - Conceptos de OOP
3 - Principios de diseño
4 - Patrones GoF, GRASP
5 - Arquitectura

Seguramente se me escape algún punto, no es importante, lo que quiero
significar es que desarrollar en net implica un conocimiento mas completo que
otras tecnologías o simplemente lenguajes.

Esto es lo que contribuye, a mi entender, a que la documentación muchas
veces no refleje nuestras necesidades, es dificil encontrar howto's que
respondan a cuestiones que vinculan muchos temas conceptuales.

Te puedo asegurar que el msdn comparado con la documentación oficial de sun
para el sdk de java es un lujo.

Hay mucha ínfo en la doc de vs, en el msdn completo, solo pasa que muchas
veces no es fácil buscar o saber bajo que terminos hacerlo.

net framework tiene su curva de aprendizaje, hay que tener paciencia y si es
posible leer mucho sobre OOP ( entendiendo por esto casi todos los items
enumerados antes ), solo hay que armarse de paciencia.

Un abrazo desde aqui

Daniel A. Calvin
MCP


"Rafael" wrote:

Eso demuestra que en C# se puede hacer muchas mas cosas de lo que uno cree.
Solo es cuestion de irlas sabiendo poco a poco.
Hay que decir que la documentacion de Visual Studio no ayuda mucho para uno
"descubrir" como hacer ese tipo de cosas.



"Pedro" escribió en el mensaje
news:O22%
>
> Wao... pocas veces se ve una explicación tan profesional y detallada. No
> sólo captaste hábilmente el concepto de lo que yo buscaba sino que diste
> varias soluciones.
>
> Te estoy muy agradecido por la ayuda.
>
> Muchos saludos.
>
> Pedro
>
>
> "Daniel A. Calvin" wrote in
> message news:
>> Hola Pedro
>>
>> ( escribi bastante, si no te gusta la primer opcion, mira la segunda )
>> La primera se usa:
>>
>> Form Form1 = new Form1();
>> if (ExisteInstanciaMiObjetoEn(Form1))
>> Console.WriteLine("Form1 tiene asiganda la instancia de
>> algun objeto en MiObjeto, Si!!!!!");
>> else
>> if (ExisteMiObjetoEn(Form1))
>>
>> ( pero requiere que implementes interfaces )
>>
>> La segunda no requiere ninguna interface y se usa:
>>
>> Form1 f=new Form1();
>> object o = GetObjetoDesde(f, "MiObjeto");
>> ( luego pregunta si o es null o no. )
>>
>> Va la explicación..
>>
>>
>> Veo que el tema se ha puesto pesado, muchas respuestas
>>
>> Tenes dos formas de hacer esto, una sería confiando en los tipos, la otra
>> por reflection, tal como menciono alguien.
>>
>> Hay factores determinantes para utilizar una u otra, a mi me gusta mas la
>> primera y te digo como la implementaria.
>>
>> Paso uno:
>>
>> Defino una interface que contemple el objeto que te interesa, algo asi:
>>
>> interface IXxxx
>> {
>> object MiObjeto { get; set; }
>> }
>>
>> En los formulario que deban tener la propiedad MiObjeto hago:
>>
>> public partial class Form1 : Form, IXxxx
>>
>> Form1 implementa la interface IXxxx
>>
>> Luego escribo donde yo quiera la funcion que averigua si existe la
>> MiObjeto:
>>
>> bool ExisteMiObjeto(object o)
>> {
>> return((o as IXxxx) != null);
>> }
>>
>> Ahora escribo otra que me dice si existe una instancia asignada a
>> MiPropiedad
>>
>> bool ExisteInstanciaMiObjetoEn(object o)
>> {
>> if (ExisteMiObjetoEn(o))
>> if ((o as IXxxx).MiObjeto != null)
>> return true;
>> return false;
>> }
>>
>> Como se usa esto?
>>
>> Un ejemplo:
>> Form Form1 = new Form1();
>> if (ExisteInstanciaMiObjetoEn(Form1))
>> Console.WriteLine("Form1 tiene asiganda la instancia de
>> algun objeto en MiObjeto, Si!!!!!");
>> else
>> if (ExisteMiObjetoEn(Form1))
>> {
>> Console.WriteLine("Existe una referencia llamada mi
>> Objeto, pero no tiene asignada ninguna instancia !!!!");
>> }
>> else
>> {
>> Console.WriteLine("Form1 no tiene una propiedad
>> llamada
>> MiObjeto");
>> }
>>
>> Esto me parece lo mas seguro, ya que se puede chequear tipos en tiempo e
>> ejecución.
>>
>>
>>
>> Si esto no es lo que queres y necesitas que se resuelva en tiempod e
>> ejecución podes hacer esto otro, este no reuiqere que declares ninguna
>> interface , ni nada, de hcho te sirve para cualquier objeto, no solo un
>> formulario.
>>
>> Debes arriba hacer:
>>
>> Using System.Reflection;
>>
>> En algun lugar escribir este metodo:
>>
>> static bool ExisteVariableEn(Form contenedor, string miObjeto)
>> {
>> Type t = contenedor.GetType();
>>
>> try
>> {
>> PropertyInfo pi = t.GetProperty(miObjeto);
>> return true;
>> }
>> catch (Exception ep)
>> {
>> try
>> {
>> FieldInfo fi = t.GetField(miObjeto);
>> return true;
>> }
>> catch(Exception ef)
>> {
>> return false;
>> }
>>
>> }
>>
>>
>> }
>>
>> Le pasaras como parametros el formulario, no una cadena con su nombre, el
>> objeto) y el nombre de la propiedad o campo. ( eso si sera una string )
>>
>> Ejemplo de uso:
>>
>> Form1 f=new Form1();
>> bool b=ExisteVariableEn( f,"MiObjeto");
>>
>> De esta forma vas a saber si existe una variable con el nombre que te
>> interesa.
>> Ahora si quieres saber si referencia a algun objeto escribi otro metodo:
>>
>>
>> static object GetObjetoDesde(object contenedor, string miObjeto)
>> {
>> Type t = contenedor.GetType();
>>
>> try
>> {
>> PropertyInfo pi = t.GetProperty(miObjeto);
>> return pi.GetValue(contenedor,null);
>> }
>> catch (Exception ep)
>> {
>> try
>> {
>> FieldInfo fi = t.GetField(miObjeto);
>> return fi.GetValue(contenedor);
>> }
>> catch (Exception ef)
>> {
>> return null;
>> }
>>
>> }
>> }
>>
>> Ejemplo de uso:
>>
>> Form1 f=new Form1();
>> object o = GetObjetoDesde(f, "MiObjeto");
>>
>>
>> Espero te gusten, me llevo un ratito armarlo
>>
>> Daniel A. Calvin
>> MCP
>>
>>
>> "Pedro" wrote:
>>
>>> Como saber si un objeto de determinado tipo (clase) se encuentra
>>> instanciado?
>>>
>>> Ej. public static bool ExisteObjeto(string cRutaObjeto)
>>>
>>> //Ejemplo: bool ExisteMiobjeto=ExisteObjeto("Form1.MiObjeto")
>>>
>>> Pedro
>>>
>>>
>>>
>
>

Te puedo asegurar que el msdn comparado con la documentación oficial de
sun
para el sdk de java es un lujo.

Hay mucha ínfo en la doc de vs, en el msdn completo, solo pasa que muchas
veces no es fácil buscar o saber bajo que terminos hacerlo.

Yo voy a hablar por mi caso en cuanto a la documentación de VS, esa que
aparece cuando doy F1 en el IDE.

Me estoy iniciando en C# y tambien pienso igual que Rafael de que la
documentacion deja mucho que desear, yo (igual que otros que han preguntado
cosas parecidas) he querido tratar de encontrar sin exito cosas no obvias
como: Es mas eficiente usar Sqlclient que usar Common para sql server?,
Porque un datatable no aparece en el toolbox, es que no se deben usar
independientemente?, las propiedades dinamicas son modificables
programaticalmente?, como hacer aparecer un control de usuario en la
toolbox?, como pongo una propiedad de usuario en la ventana de propiedades?
como agrego tablas de una clase heredada a mi dataset visualmente?, le puedo
indicar a mi dataset heredado, cual es la clase de datatables a agregar?
que significa cada atributo, o mejor dicho, que son los atributos tal como
los trata .NET (me refiero a una definicion conceptual. Vamos no tengo por
que saber todo..)?, es mas eficiente un dataset tipado que uno no tipado?,
por que debo usar tableadapters?, puedo solo usar datatables para manejar
datos ignorando los datasets?, son realmente necesarios los datasets?,
..bindingsource y bindingcontext, cuando usar una u otra? puedo modificar
mis librerias de clases mientras las utilizo en mi proyecto windows
abierto?, por que el commandbuilder no me pone en el where de un
updatecommand solo la comparacion de la clave primaria sino que pone todos
los campos de la datatable? .. como hago para cambiar el comportamiento de
un bindingnavigator?... por que Dataset1.designer.cs genera mas de 1000
lineas de codigo si solo quiero manejar una tablita con dos columnas ...
etc... etc..etc... etc...

Finalmente las voy resolviendo poco a poco, si es posible y mi trabajo me lo
permite, pasando dias de busqueda e impresion en google, en colabora.net,
el guille y en foros importantes como este.
Quizas la informacion esta ahi en la documentacion pero sencillamente no es
facil de encontrar, como dices. Para los novatos nos resulta dedicar un
tiempo excesivo para dar los primeros pasos. Yo vengo de otros lenguajes y
plataformas y es la primera vez que me resulta tan complejo iniciarme en una
plataforma nueva tratando de basarme de inicio en su propia documentacion.
.NET no es nada simple. Los lenguajes despues de .NET volvieron a ser
dificiles.

Esa es mi opinion.

Saludos y te exhorto a que sigas participando y colaborando ya que no te veo
mucho por aquí.

José TH

Hola Octavio,

On 12 apr, 12:47, "Octavio Hernandez"
wrote:

Hola, Carlos!

>> Para mi lo mejor sería tener solo un tipo String.

Sí, eso suena totalmente razonable...

>> Claro, el significado del == depende entonces de los tipos/clases

y eso embrolla el lenguaje. Determinar la igualdad de valores
en distintas variables es un concepto muy básico en programación
y debería ser consistente.

También tiene toda la lógica del mundo lo que dices, pero por otra
parte... ¿no os "repateaba" tener que escribir

if (s2.equals(s1)) ...

para comparar dos cadenas en Java? A mí sí...

Si, sobre todo con cadenas, que se suelen percibir como un
tipo primitivo.
Otra opción hubiera sido operadores especiales para el equals()
y el clone() porque es solo un cuestión de sintaxis.

Y lo q es peor, q sin darte cuenta puedes decir

if (s2 == s1)

y estarías comparando las referencias cuando lo que querías era
comparar los valores...

Ya! Te entiendo. Pero es que las referencias *son* los valores
de las variables s1 y s2! :-)
Me recuerda también al problema de comparar con = en vez de ==.

De todas formas sigue siendo necesario poder distinguir entre
'son a y b iguales?' y 'son a y b el mismo?', que no es lo
mismo :) Un problema general; no solo en Java y C#.

Saludos,
Carlos