2010-12-04 21 views
13

Empiezo a leer el código fuente de Lift Framework, me parece que hay tantos métodos definidos con un nombre como methodName_?, ¿hay alguna convención que _? tenga algún significado especial?¿Por qué la gente usa _? como un sufijo identificador?

def empty_? : Boolean = {} 
+0

Pregunta similar: http://stackoverflow.com/questions/1598410/use-of-special-characters-in-function-names – aioobe

Respuesta

24

El ? denota que este es un predicado, una función que devuelve Boolean. Esta convención se remonta a Lisp, donde ? (Esquema), p o -p (otros Lisps, que simulan el signo de interrogación con una letra "similar") también denotan predicados. Piénselo como preguntando "¿está vacío el objeto?"

Scala solo permitirá nombres de identificadores mixtos (que contengan caracteres alfanuméricos y signos de puntuación) si los separa por _. Por ejemplo,

scala> def iszero?(x : Int) = x == 0 
<console>:1: error: '=' expected but identifier found. 
     def iszero?(x : Int) = x == 0 
       ^

no funciona, pero

scala> def iszero_?(x : Int) = x == 0   
iszero_$qmark: (x: Int)Boolean 

hace.

+1

Lea la pregunta demasiado rápido. He eliminado el mío y voté esto. – duffymo

26

Es poco probable que vea la construcción fuera del marco de elevación; Sospecho que es principalmente Ruby-envidia.

Casi cualquier otro proyecto de Scala se alejará de esta sintaxis. No por el signo de interrogación final, sino porque es otra forma de introducir guiones bajos en el código, y el símbolo ya está demasiado sobrecargado.

Según la evaluación de varios proyectos de Scala, la notación puede describirse razonablemente como no idiomática.

ACTUALIZACIÓN

La razón por la que no se requiere el subrayado es para eliminar la ambigüedad de notación infija, en los cuales:

x?y 

podría leerse como

x.?(y) 

con ? ser una nombre del método. Considerando lo siguiente:

x_?y 

demarca Claramente x_? como atómica.

La sintaxis es un ejemplo de lo que se conoce formalmente como un "identificador mixto", y está destinado a permitir definiciones tales como

def prop_=(v:String) = ... //setter 
def unary_- = ... //prefix negation operator 

Podría (posiblemente) ser considerado un corte cuando se utiliza construcción similar simplemente para empujar un signo de interrogación al final del nombre de un método.

+3

"el símbolo ya está demasiado sobrecargado" Como un token separado, seguro, pero no dentro de los identificadores. –

+3

@Alexey Romanov: Aún así, esto va en contra de la convención Scala de usar CamelCase y dromedaryCase en identificadores. –

+0

Sí, demasiados guiones bajos en el código fuente de Scala.En Lift, hay guiones bajos en todas partes, como: ParsePath (List ("account", acctName), _, _, _), _, _), tienes que escribir toneladas de ParsePath de esta manera. – Sawyer

Cuestiones relacionadas