A nadie le importa una mierda, pero... v12

[EmuAGR]

(10-18-2011, 06:59 PM)Yumichan escribió: Es que eso último, new String ("17") es redundante.
Los literales de cadena son objetos en Java, tal cual.
String hola= "hOla".toUpperCase(); // "HOLA"
Ese literal no es { 'h', 'O', 'l', 'a', '\0'}, es un objeto con todas sus cosas.

He ahí una inconsistencia de Java. String es un objeto, debería declararse como tal usando el constructor adecuadamente y no como un tipo simple.

Y LoKo, me daba pereza hacer un bucle para reemplazar la cadena por "17+2". Pero tienes razón. xD

[Reboot]

El problema es que usáis la clase equivocada. Si queréis trabajar con cadenas no tenéis que usar String, sino Stringbuffer.

Cuando añadís o substraéis caracteres a un String, el compilador hace lo siguiente:

String -> [new] Stringbuffer -> [Operaciones] -> [new] String

Porque el objeto String es inmutable, ya que la clase nativa es char y String es un array de chars, mientras que Stringbuffer es un vector.

Cuando haces.

Código:

String hola= "hOla".toUpperCase(); // "HOLA"

El compilador crea el String "hOla", lo convierte a buffer, lo modifica a HOLA y lo vuelve a convertir a String.
Si tomas la costumbre de usar siempre Stringbuffer te ahorras dos objetos y dos casts.

Y no, no es ninguna inconsistencia. Es llevar la orientación a objetos a sus máximas consecuencias. Es más, diría que fueron consistentes en exceso a la hora de no hacer nativa la clase String.

[Yumichan]

(10-19-2011, 08:56 AM)Reboot escribió: El problema es que usáis la clase equivocada. Si queréis trabajar con cadenas no tenéis que usar String, sino Stringbuffer.

Cuando añadís o substraéis caracteres a un String, el compilador hace lo siguiente:

String -> [new] Stringbuffer -> [Operaciones] -> [new] String

Porque el objeto String es inmutable, ya que la clase nativa es char y String es un array de chars, mientras que Stringbuffer es un vector.

Es lo que trato de explicar desde hace 1 página, pero no leeis... , aparte de comentar que si no hay multiples hilos StringBuilder es ligeramente mejor ( x 2 )

(10-19-2011, 08:56 AM)Reboot escribió: Cuando haces.

Código:

String hola= "hOla".toUpperCase(); // "HOLA"

El compilador crea el String "hOla", lo convierte a buffer, lo modifica a HOLA y lo vuelve a convertir a String.
Si tomas la costumbre de usar siempre Stringbuffer te ahorras dos objetos y dos casts.

Era una forma de demostrale a EmuAGR, que un literal de cadena es un objeto de la clase String y como tal puedes usar sus métodos sobre él. Puedes poner cualquier otro ejemplo.

EmuAGR escribió:He ahí una inconsistencia de Java. String es un objeto, debería declararse como tal usando el constructor adecuadamente y no como un tipo simple.

Por poder se puede continuar viendo cosas raras ad infinitum (a Java y a todos los lenguajes), pero IMHO obligar a hacer new con literales de cadena:
a ) Sería una chapuza obligar a hacerlo siempre, new String (String) "copia" contenido. Lo tienes en un sitio y es inmutable, pa' qué mas (salvo los casos concretos para aligerar el GC).
b ) Es lo mismo de antes, es por estar pensando que un literal es un tipo simple como los char* de C. ¡El propio literal es un objeto!, ¡el compilador lo ve como un objeto!, sólo hay que pensar en él como tal.
c ) Java permite que todas las clases que mapean tipos simples (Char, Integer, Double, etc) admiten instanciación desde sus tipos de datos simples. De pensar que b ) es una inconsistencia del lenguaje, c ) viene a uniformizarlo.

No trabajo con .NET, sólo he leido cosas de pasada, a ver si alguien sabe concretar este punto, pero creo que salvo el punto c ) estos lenguajes se comportan como Java porque supone una ventaja evidente.

Pero podemos hablar de ponis y que Frikitty haga flame (lo de los ponis va en serio, le pega a Java XD)

[EmuAGR]

Chapuzas, chapuzas everywhere. Un puto juego de cubos pixelizados que a veces laguea en mi i7 920 con una ATI HD5850 y que no pueden hacer nada porque se piratee... xD

La idea es buena, la ejecución pésima.

[Nobi]

Visto así, puede parecer una caca. Pero ten en cuenta que para lograr un escenario totalmente maleable ha de renunciar a la mayoría de las técnicas de optimización que usan los motores gráficos y renderizar "a pelo" escenarios de un tamaño bastante considerable. Y eso sin tener en cuenta que el programa debe también conocer las características del material de cada bloque.

[❤•❀Kharn❀•❤]

Me encanta ver cómo EmuAGR cambia de tema "porque sí" cuando le están owneando.

Primero aprende los conceptos básicos de Java y de la OO, y luego criticas lo que quieras.

[FriKitty]

(10-19-2011, 09:28 AM)Yumichan escribió: Pero podemos hablar de ponis y que Frikitty haga flame (lo de los ponis va en serio, le pega a Java XD)

Me encanta porque he estado ignorando estos últimos post ya que no me enteraba de una puta mierda, y he ido a fijarme en mi nick dentro de ese pedazo de tochopost tuyo.

Los ponis lo petan.

Y ANLIUM pero como no tengo nada que hacer hasta las ocho, me pondré a subtitular ponis.

[Nobi]

Unos bichos tan requetesucios no pueden ser monos

[Maquhatulieltl]

(10-19-2011, 02:08 PM)FriKitty escribió: Los ponis me petan.

Fixed

[CucuFaiter]

(10-19-2011, 04:32 PM)Maquhatulieltl escribió:

(10-19-2011, 02:08 PM)FriKitty escribió: Los ponis me petan.

Fixed

Ved 2 men 1 horse. Os tirareis todo el dia diciendo "¡OGH!".

Y ANLIUM, pero el ending de esta temporada de "Game Over" es así de chulo.



Temazo. Me he bajado la OST de todos los Silent Hill después de esto. A ver si juego a alguno después de esto.

Y ANLIDM, pero pienso pillarme esto si hacen envios internacionales no muy caros.