Compilación de errores de Scala OptionBuilder

Estoy usando Apache commons cli (1.2) para el análisis de línea de comandos.Compilación de errores de Scala OptionBuilder

Tengo el siguiente en mi código:

import org.apache.commons.cli.OptionBuilder 
OptionBuilder.withLongOpt("db-host").hasArg. 
withDescription("Name of the database host").create('h')

me sale el error hasArg is not a member of org.apache.commons.cli.OptionBuilder. No hace ninguna diferencia si cambio .hasArg a .hasArg().

¿Por qué?

BTW, Java lo analiza bien.

Fuente

2011-02-04 Ralph

(Recordatorio: Activar advertencias en javac/Eclipse/donde sea.) –

@pst: Los tengo en. Estoy trabajando en Netbeans (mejor soporte de Scala, en mi humilde opinión) y subrayó el método 'hasArg'. Preferiría trabajar en IntelliJ, pero el complemento Scala tiene algunos errores graves con el código de reformateo. He enviado informes de fallas, pero hasta el momento, no se han publicado correcciones. – Ralph

import org.apache.commons.cli.OptionBuilder 
OptionBuilder.withLongOpt("db-host").hasArg. 
withDescription("Name of the database host").create('h') 
me sale el error hasArg is not a member of org.apache.commons.cli.OptionBuilder. No hace ninguna diferencia si cambio .hasArg a .hasArg().

¿Por qué?

Debido no existe un método ejemplo hasArg en OptionBuilder, solamente un método estático. Como hasArg es un método estático, es obvio que debe llamarlo a la clase, no a una instancia de la clase.

BTW, Java lo analiza bien.

No entiendo qué tiene que ver esto con el análisis. Scala también lo analiza bien. Además, lo que una programación completamente diferente hace o no con este código es completamente irrelevante, ya que este es el código Scala, no otro lenguaje.

que tiene que hacer algo como esto:

import org.apache.commons.cli.OptionBuilder 

OptionBuilder.withLongOpt("db-host") 
OptionBuilder.hasArg 
OptionBuilder.withDescription("Name of the database host") 

val optionParser = OptionBuilder.create('h')

Fuente

2011-02-04 22:03:21

¡Ergh, este OptionBuilder tiene una interfaz horrible! – pedrofurla

@pedrofurla: Funciona accidentalmente en Java, porque en Java se pueden invocar métodos estáticos en una instancia, y si no hay un método de instancia correspondiente, en lugar de generar un error, el sistema lo convertirá silenciosamente en una llamada a un método estático para tú. Por lo tanto, en Java, * se ve como * una interfaz fluida que utiliza el encadenamiento de métodos, cuando en realidad no lo es. La forma correcta de hacer esto, probablemente sería usar un objeto de estado intermedio para capturar las llamadas al método, tal vez incluso algún tipo de máquina de estado de tipo. –

La palabra importante en mi comentario anterior es, por supuesto, "accidentalmente". Como @pst se insinuó anteriormente, esto * generará * una advertencia severa en prácticamente cualquier IDE y/o editor de Java, y la mayoría de los revisores de estilo (CheckStyle, PMD, ...) lo rechazarán. –

Compilación de errores de Scala OptionBuilder

Respuesta

Cuestiones relacionadas