Ausencia de sintaxis de propiedad en Java

Question

C# tiene sintaxis para declarar y usar propiedades. Por ejemplo, se puede declarar una propiedad como la que sigue:

public int Size { get; set; } 

También se puede poner un poco de lógica en la propiedad, así:

public string SizeHex 
{ 
    get 
    { 
     return String.Format("{0:X}", Size); 
    } 
    set 
    { 
     Size = int.Parse(value, NumberStyles.HexNumber); 
    } 
} 

Independientemente de si se tiene lógica o no , una propiedad se utiliza en la misma forma que un campo:

int fileSize = myFile.Size; 

no soy ajeno a Java o C# - yo he usado tanto mucho y siempre he echado de menos tener sintaxis de la propiedad en Java. He leído en this question que "es muy poco probable que se añada soporte de propiedad en Java 7 o tal vez", pero francamente me resulta demasiado trabajo cavar en discusiones, foros, blogs, comentarios y JSR para averiguar por qué .

Así que mi pregunta es: ¿alguien puede resumir por qué Java no es probable que obtenga la sintaxis de la propiedad?

• ¿Es porque no se considera lo suficientemente importante en comparación con otras posibles mejoras?
• ¿Existen limitaciones técnicas (por ejemplo, relacionadas con JVM)?
• ¿Es una cuestión de política? (por ejemplo, "He estado codificando en Java desde hace 50 años y digo que no necesitamos propiedades steenkin '!")
• ¿Es un caso de bikeshedding?

Answer 1

Creo que es solo la filosofía general de Java hacia las cosas. Las propiedades son algo "mágicas", y la filosofía de Java es mantener el lenguaje central lo más simple posible y evitar la magia como la peste. Esto permite que Java sea una lingua franca que pueda ser comprendida por cualquier programador. También hace que sea muy fácil razonar sobre lo que está haciendo una pieza de código aislada y arbitraria, y permite un mejor soporte de herramientas. La desventaja es que hace que el lenguaje sea más detallado y menos expresivo. Esta no es necesariamente la forma correcta o la incorrecta de diseñar un idioma, es solo una compensación.

Answer 2

Las propiedades parecen más como un factor limitante en mi opinión. No veo particularmente un necesita para las propiedades.

Answer 3

Puede ser útil para agregar a Java, pero probablemente no sea tan alto en la lista como los cierres.

Personalmente, encuentro que un IDE decente hace que este sea un punto discutible. IntelliJ puede generar todos los getters/setters para mí; todo lo que tengo que hacer es integrar el comportamiento que hiciste en los métodos. No creo que sea un factor decisivo.

Admitiré que no estoy bien informado sobre C#, por lo que quizás los que lo son me invaliden. Esta es sólo mi opinión.

Answer 4

Yo diría que refleja la lentitud del cambio en el idioma. Como mencionó un comentarista anterior, con la mayoría de los IDE ahora, realmente no es tan importante. Pero no hay razones específicas de JVM para que no esté allí.

Answer 5

Durante 10 años más o menos, el sol se ha resistido a cualquier cambio significativo en el idioma tan duro como hubiera podido. En el mismo período, C# ha atravesado un desarrollo fascinante, y ha añadido una serie de nuevas funciones increíbles con cada lanzamiento.

Creo que el tren dejó en propiedades en Java hace mucho tiempo, habrían sido agradables, pero tenemos la especificación java-bean. Agregar propiedades ahora solo haría el lenguaje aún más confuso. Si bien la especificación javabean IMO no es ni de lejos tan buena, tendrá que hacer. Y en el esquema más grandioso de las cosas, creo que las propiedades no son tan relevantes. El código de hinchazón en java es causado por otras cosas que no sean getters y setters.

Hay cosas mucho más importantes para enfocarse, como obtener un estándar de cierre decente.

Answer 6

argumentos posibles en base a nada más que mi opinión desinformada

• la sintaxis de la propiedad en C# es un feo hackear en el que se mezcla un patrón aplicación con la sintaxis lenguaje
• No es realmente necesario , ya que es bastante trivial.
• Afectaría adversamente a cualquier persona que pagara en función de las líneas de código.

Realmente me gustaría que haya algún tipo de azúcar sintáctico para las propiedades, ya que toda la sintaxis tiende a saturar el código que es conceptualmente extremadamente simple. Ruby por uno parece hacer esto sin mucho alboroto.

En una nota al margen, en realidad he tratado de escribir algunos sistemas de tamaño mediano (unas pocas docenas de clases) sin acceso a la propiedad, solo por la reducción del desorden y el tamaño de la base de código. Aparte de los problemas de diseño inseguros (que estaba dispuesto a fudge en ese caso) esto es casi imposible, ya que cada framework, cada biblioteca, todo en java descubre automáticamente las propiedades por los métodos get y set. Están con nosotros hasta el momento. fin de los tiempos, algo así como pequeñas ruedas de entrenamiento sintáctico.

Answer 7

Es la misma razón por la que no cambian nada más en Java: compatibilidad con versiones anteriores.

Answer 8

La sintaxis de la propiedad en C# no es más que syntactic sugar. No lo necesita, solo está allí para su conveniencia. A la gente de Java no le gusta el azúcar sintáctico. Eso parece ser razón suficiente para su ausencia.

Answer 9

- ¿Es porque no se considera lo suficientemente importante en comparación con otras posibles mejoras?

Esa es mi suposición.

- ¿Existen limitaciones técnicas (por ejemplo, relacionadas con JVM)?

Sin

- ¿Es una cuestión de la política? (Por ejemplo, "He estado de codificación en Java desde hace 50 años y digo: no necesitamos ninguna propiedad steenkin")

más probable.

- ¿Es un caso de bikeshedding?

¿Uh?

Uno de los principales objetivos de Java era mantener el lenguaje simple.

Del: Wikipedia

Java suprime varias características [...] para las clases con el fin de simplificar el lenguaje y para evitar posibles errores y diseño anti-patrón.

Answer 10

Éstos son unos pequeños trozos de lógica que, para mí, conducen a que no le gustaba propiedades en un idioma:

Algunas estructuras de programación se acostumbren porque están ahí, incluso si son compatibles con mala programación prácticas.

Los setters implican objetos mutables. Algo para usar escasamente.

Un buen diseño de OO le pide a un objeto que haga algo de lógica de negocios. Las propiedades implican que usted está solicitando datos y manipulando los datos usted mismo.

Aunque puede anular los métodos en setters y getters, pocos lo hacen; también una variable pública final es EXACTAMENTE la misma que un getter. Entonces, si no tienes objetos mutables, es un punto discutible.

Si su variable tiene lógica comercial asociada, la lógica debería estar GENERALMENTE en la clase con la variable. Si no es así, ¿por qué en el mundo es una variable? debe ser "Datos" y estar en una estructura de datos para que pueda ser manipulado por código genérico.

---

Creo que Jon Skeet señalado que C# tiene un nuevo método para el manejo de este tipo de datos, datos que deben escribirse en tiempo de compilación, pero realmente no deben ser variables, pero es que mi mundo tiene muy poca interacción con el mundo de C#, voy a tomar su palabra de que es genial.

Además, acepto totalmente que dependiendo de su estilo y el código con el que interactúa, simplemente TIENE que tener una situación set/get de vez en cuando. Todavía promedié un setter/getter en cada clase o dos, pero no lo suficiente como para hacerme sentir que se justifica una nueva estructura de programación.

Y tenga en cuenta que tengo requisitos muy diferentes para el trabajo y la programación del hogar. Para el trabajo donde mi código debe interactuar con el código de otras 20 personas, creo que cuanto más estructurado y explícito, mejor. En casa Groovy/Ruby está bien, y las propiedades serían grandiosas, etc.

Answer 11

Si tuviera que adivinar, diría que tiene menos que ver con una objeción filosófica al azúcar sintáctico (añadieron autoboxing, mejorado para bucles , importación estática, etc., todo azúcar) que con un problema de compatibilidad con versiones anteriores. Hasta ahora, al menos, los usuarios de Java han intentado diseñar las nuevas características del lenguaje de forma tal que se mantenga la compatibilidad hacia atrás del nivel de fuente (es decir, el código escrito para 1.4 seguirá compilando y funcionando, sin modificaciones en 5 o 6 o más allá).

Supongamos que introducen la sintaxis de las propiedades.¿Qué, entonces hace lo siguiente media:

myObj.attr = 5; 

Que dependerá de si se está hablando de código escrito antes o después de la adición de las propiedades cuentan, y posiblemente en la definición de la propia clase.

No digo que estos problemas no se puedan resolver, pero soy escéptico de que se puedan resolver de una manera que conduzca a una sintaxis limpia y sin ambigüedades, a la vez que se preserva la compatibilidad con las versiones anteriores.

La gente pitón puede ser capaz de salirse con romper el código de edad, pero esa no es la manera de Java ...

Answer 12

De acuerdo con el volumen 2 de Core Java (olvidado los autores, pero es un libro muy popular), los diseñadores de idiomas pensaron que era una mala idea ocultar una llamada de método detrás de la sintaxis de acceso de campo, y así lo dejamos fuera.

Answer 13

Puede que no necesite para "obtener" y "set" prefijos, para que se vea más como propiedades, puede hacerlo de esta manera:

public class Person { 
    private String firstName = ""; 
    private Integer age = 0; 

    public String firstName() { return firstName; } // getter 
    public void firstName(String val) { firstName = val; } // setter 

    public Integer age() { return age; } // getter 
    public void age(Integer val) { age = val; } //setter 

    public static void main(String[] args) { 
     Person p = new Person(); 

     //set 
     p.firstName("Lemuel"); 
     p.age(40); 

     //get 
     System.out.println(String.format("I'm %s, %d yearsold", 
      p.firstName(), 
      p.age()); 
    } 
}