no entiendo esta expresión

[bandok-reload]

hola alguien me podria explicar que hace o que significa el (String) en esta expresión

String nombre = (String) criteriosBusqueda.get("NOMBRE");


Saludos

[Gordenay]

Buenas

lo que hace es transformar a String el valor que devuelve la función

criteriosBusqueda.get("NOMBRE")

por ejemplo si la función devuelve un 1, (String) lo transforma a "1"

[Bunburyscom]

Hola,

Estas conviertiendo lo que recuperas de criteriosBusqueda.get("NOMBRE")
a String, ya que estoy seguro que te devuelve un tipo de dato de tipo Object y por eso hay que hacerle ese cast.

saludos!

[bandok-reload]

entonces es como que hiciera:
String nombre = criteriosBusqueda.get("NOMBRE").toString();

[PachuG]

String nombre = (String) criteriosBusqueda.get("NOMBRE");
Peligrosa expresion !!!
FUNCIONA ?????????
Creo que siempre que sea un String funcionara.

// Esta me parece Mejor
String nombre = criteriosBusqueda.get("NOMBRE").toString();

Siempre y cuando sea un object y tenga redifinido el metodo toString(), si no devolvera cualquier cosa creo (por supuesto a menos que sea un String)

Y para los tipos de datos primitivos como int, long, double, etc?

Bueno cada tipo de dato tiene un Wrapper que poseen metodos para convertir a String cada uno de estos.

Por ej. para devolver el String de un entero

Integer.valueOf(int);

Creo que para los demas wrappers es el mismo metodo

Por ej. Double.valueOf(int)

Estos metodos devuelven Strings

Su signatura o cabecera de metodo,(no recuerdo la expresion, creo que es lo mismo), seria

String valueOf(int valor)

//////////////////************///////////////////////
En este caso creo que esta queriendo acceder al campo de una bd
Me parece que no hace falta el casteo, ya que por el nombre del campo sera un String y por supuesto que quien hace la aplicacion sabra bien que es.

String nombre = (String) criteriosBusqueda.get("NOMBRE");

Tranquilamente puede convertirse en

String nombre = criteriosBusqueda.get("NOMBRE");

O sea, el casteo para mi no hace nada, mas que dificultar la lectura y seguro que trabajo al pedo.

Suerte..., espero que haya aclarado un poco

[GreenEyed]

lo que hace es transformar a String el valor que devuelve la función

criteriosBusqueda.get("NOMBRE")

por ejemplo si la función devuelve un 1, (String) lo transforma a "1"

Tranquilamente puede convertirse en

String nombre = criteriosBusqueda.get("NOMBRE");

O sea, el casteo para mi no hace nada, mas que dificultar la lectura y seguro que trabajo al pedo.

No y no .

Primero: El cast no transforma nada. Si criteriosBusqueda.get("NOMBRE") devuelve un numero, 1, el cast no lo transformará en una cadena, "1", si no que saltará un error -> que es lo que debe ocurrir.

Segundo: El cast es necesario y hacer un toString() es un error por que el cast debe dar un error si lo que te devuelve el get no es un String. Si no, lo unico que estas haciendo es enmascarar un error de tu programa, cosa que nunca se debe hacer por que si no, puede que nunca descubras que existe.

El cast es una declaración tuya al compilador para decirle "se lo que va a devolver ese metodo y es esto", para que el compilador te deje usar el valor devuelto como de la clase que tu le has asegurado que va a a ser. Si el metodo no devuelve eso, y debería, es que tu programa está mal y debes corregirlo.

El cast no es para dificultar la lectura, es una declaración de intenciones de que sabes exactamente lo que estas haciendo para que el compilador te deje trabajar asumiendo "riesgos".

S!

[PachuG]

GreenEyed, me parece que esa sentencia es para acceder al campo de una base de datos, el cual dicho campo sera de tipo de dato String. Si hay un uno en la bd no importa, no tira ningun error, ya que es un String y no un int. En caso de que el tipo de dato del campo sea distinto de String, pues con esta expresion es suficiente

String nombre = criteriosBusqueda.get("NOMBRE");

ya que al poner String nombre = ... le estas diciendo al compilador que esperas un String. Ahora no recuerdo si el chequeo lo hace en tiempo de compilacion como si fuese un objeto comun al que le aplicas el metodo get, el cual te lanzaria un error que dice algo como que se esperaba un String, o si lo hace en tiempo de ejecucion, el cual lanzaria una excepcion (de tipo SQL... creo) la cual no recuerdo (Perdon por hacer todo a medias). Esta excepcion sera catcheada por el catch que rodea esta sentencia, ya que el compilador no te permite poner esta expresion sin rodear de try - catch. En todos los casos creo que el cast realmente no importa. Si me equivoco por favor corrigeme y sacame de dudas de lo que acabo de comentar.
Gracias...

[Bunburyscom]

Iniciado por GreenEyed

No y no .

Primero: El cast no transforma nada. Si criteriosBusqueda.get("NOMBRE") devuelve un numero, 1, el cast no lo transformará en una cadena, "1", si no que saltará un error -> que es lo que debe ocurrir.

Segundo: El cast es necesario y hacer un toString() es un error por que el cast debe dar un error si lo que te devuelve el get no es un String. Si no, lo unico que estas haciendo es enmascarar un error de tu programa, cosa que nunca se debe hacer por que si no, puede que nunca descubras que existe.

El cast es una declaración tuya al compilador para decirle "se lo que va a devolver ese metodo y es esto", para que el compilador te deje usar el valor devuelto como de la clase que tu le has asegurado que va a a ser. Si el metodo no devuelve eso, y debería, es que tu programa está mal y debes corregirlo.

El cast no es para dificultar la lectura, es una declaración de intenciones de que sabes exactamente lo que estas haciendo para que el compilador te deje trabajar asumiendo "riesgos".

S!

Totalmente de acuerdo contigo !!!!

Saludos!

[GreenEyed]

Iniciado por PachuG

GreenEyed, me parece que esa sentencia es para acceder al campo de una base de datos, el cual dicho campo sera de tipo de dato String.

Si, eso es lo que parece.

Iniciado por PachuG

Si hay un uno en la bd no importa, no tira ningun error, ya que es un String y no un int. En caso de que el tipo de dato del campo sea distinto de String, pues con esta expresion es suficiente

String nombre = criteriosBusqueda.get("NOMBRE");
ya que al poner String nombre = ... le estas diciendo al compilador que esperas un String.

Error. Esa asignación ni siquiera compila por que criteriosBusqueda.get("NOMBRE"); devuelve un Object y el compilador quiere que tu le asegures explicitamente que será un String. Y ese "explicitamente" es escribir un cast. Con lo que tu pones simplemente le dices que tu variable es del tipo String, nada más.

Iniciado por PachuG

Ahora no recuerdo si el chequeo lo hace en tiempo de compilacion como si fuese un objeto comun al que le aplicas el metodo get, el cual te lanzaria un error que dice algo como que se esperaba un String, o si lo hace en tiempo de ejecucion, el cual lanzaria una excepcion (de tipo SQL... creo) la cual no recuerdo (Perdon por hacer todo a medias). Esta excepcion sera catcheada por el catch que rodea esta sentencia, ya que el compilador no te permite poner esta expresion sin rodear de try - catch. En todos los casos creo que el cast realmente no importa. Si me equivoco por favor corrigeme y sacame de dudas de lo que acabo de comentar.
Gracias...

El compilador de Java, a diferencia de otros lenguajes de tipado dinámico o tipado debil, es muy cascarrabias (Java es de tipado fuerte) y no te deja hacer eso. El chequeo del tipo de retorno solo se puede hacer en tiempo de ejecucion, ya que no puedes asegurar qué devolverá el metodo en compilacion, pero como Java es de tipado fuerte, el compilador te obliga a declarar de que tipo va a ser lo que devuelves. Podría no hacerlo y devolvería los mismos errores en ejecución, pero en Java se escogió obligar a los programadores a escribir esas cosas para obligar a los programadores a pensar, con la esperanza de hacer los programas más robustos, al igual que otros detalles del compilador. Si se consigue o no, es otro tema .

En cuanto a la excepción, de nuevo te confundes. Un error de casting es un error no esperado y por tanto es una RuntimeException (no es "chequed") y por tanto no te obliga a hacer try/catch.

El cast "importa" en el sentido de que si no lo pones, no vas a compilar el programa. Eso ya es algo .

S!
PD: Usando Generics te puedes evitar el cast en algunos casos, pero simplemente estás moviendo la declaración explícita desde el cast a la declaración usando Generics.... o sea que lo acabas declarando igual.

[PachuG]

GreenEyed gracias por tus explicaciones y aclaraciones. No te quiero cansar con este tema pero me quedan algunas dudas y espero si no es molestia que me la puedas aclarar.

Estuve revisando la API de java, ya que hace mucho que no agarro este tema y me di cuenta que estaba equivocado .

Partiendo de que coincidimos que esta sentencia parece ser para acceder a un campo de una bd, entonces supongo que criteriasBusqueda es un objeto de tipo ResultSet, entonces me di cuenta de que:

La expresión, String nombre = criteriosBusqueda.get("NOMBRE");
es verdad, NO COMPILA.

Me confundí con String nombre = criteriosBusqueda.getString("Nombre");

la cual compilaría si no me equivoco y no necesitaría casteo.

La signatura de este metodo según la api sería

String getString(String columnName)
throws SQLException

Retrieves the value of the designated column in the current row of this ResultSet object as a String in the Java programming language.

Parameters:
columnName - the SQL name of the column
Returns:
the column value; if the value is SQL NULL, the value returned is null
Throws:
SQLException - if a database access error occurs

http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html#getInt(java.lang.String)

lo que decia de la SQLException me confundí con esta, ya que la lanza si ocurre un error al acceder a la bd, por lo que el compilador te obliga a que esta sentencia vaya rodeada de try-catch.

Coincido con vos en que si criteriosBusqueda.get("NOMBRE") devolvería un Object y necesitaría castearse a String, pero no encontré ese método en la API, por lo que te pido me pases un link a donde figure ese método y estaré muy agradecido.

Tb. coincido sobre generics, pero otra cosa que no entendí fué esto que cito a continuación con el famoso copiar-pegar ya que no sé como citar fragmentos

El compilador de Java, a diferencia de otros lenguajes de tipado dinámico o tipado debil, es muy cascarrabias (Java es de tipado fuerte) y no te deja hacer eso. El chequeo del tipo de retorno solo se puede hacer en tiempo de ejecucion, ya que no puedes asegurar qué devolverá el metodo en compilacion, pero como Java es de tipado fuerte, el compilador te obliga a declarar de que tipo va a ser lo que devuelves.

Me mareaste un poco ahí. Veamos si coincidimos.

Java realiza comprobaciones en tiempo de compilación, o sea, en una asignación entre punteros el compilador verifica que los tipos sean compatibles, si no lo son, no compila, como en el caso de String nombre = criteriosBusqueda.get("NOMBRE"); y realiza comprobaciones en tiempo de ejecución, como por ejemplo cuando se usa un cast para accesar un objeto como si fuese de un tipo específico, verificando que el objeto sea compatible con el cast que se le aplica, si no lo es lanza una RuntimeException, como en el caso de String nombre = (String) criteriosBusqueda.get("NOMBRE") suponiendo que el tipo de dato en esa columna no sea String.

Muchas gracias nuevamente por las aclaraciones, y si me podrías explicar un poco sobre el metodo get de criteriosBusqueda será bienvenido.
Saludos...

[GreenEyed]

Iniciado por PachuG

GreenEyed gracias por tus explicaciones y aclaraciones. No te quiero cansar con este tema pero me quedan algunas dudas y espero si no es molestia que me la puedas aclarar.

No problemo, la idea es aprender entre todos.

Iniciado por PachuG

Me confundí con String nombre = criteriosBusqueda.getString("Nombre");

la cual compilaría si no me equivoco y no necesitaría casteo.

Efectivamente. En este caso el metodo ya te asegura que devolverá un String, así que no tienes que decirlo tú.

Iniciado por PachuG

lo que decia de la SQLException me confundí con esta, ya que la lanza si ocurre un error al acceder a la bd, por lo que el compilador te obliga a que esta sentencia vaya rodeada de try-catch.

Error al acceder a la BDD si que se consideran "esperados", así que con "chequed excepctions" y por tanto necesitan try/catch.

Iniciado por PachuG

Coincido con vos en que si criteriosBusqueda.get("NOMBRE") devolvería un Object y necesitaría castearse a String, pero no encontré ese método en la API, por lo que te pido me pases un link a donde figure ese método y estaré muy agradecido.

Ahí es que creo que has confundido el objeto. En realidad no dice en ningun sitio que criteriosBusqueda sea un ResultSet y yo apostaría más bien que es una Collection, por eso le pide el cast pero no le pide try/catch .

Iniciado por PachuG

Me mareaste un poco ahí. Veamos si coincidimos.

Java realiza comprobaciones en tiempo de compilación, o sea, en una asignación entre punteros el compilador verifica que los tipos sean compatibles, si no lo son, no compila, como en el caso de String nombre = criteriosBusqueda.get("NOMBRE"); y realiza comprobaciones en tiempo de ejecución, como por ejemplo cuando se usa un cast para accesar un objeto como si fuese de un tipo específico, verificando que el objeto sea compatible con el cast que se le aplica, si no lo es lanza una RuntimeException, como en el caso de String nombre = (String) criteriosBusqueda.get("NOMBRE") suponiendo que el tipo de dato en esa columna no sea String.

Correcto. Lo único que quería decir es que hay lenguajes que no te obligan a hacer el cast, y suponen que tu ya sabes lo que haces. Los errores que saltan en estos lenguajes y en Java son los mismos, en Runtime si el tipo no es compatible, y la única diferencia es que en Java el compilador es más cascarrabias y te obliga a escribir el cast. Simplemente eso.

S!

[PachuG]

Muchas gracias nuevamente GreenEyed, quedó más que claro. Entonces era una colección y eso no me dí cuenta.
Un gusto aprender, y suerte!!