2010-10-12 10 views
5

¿Qué indicador utiliza para la declaración de miembro en F #? Yo prefieroF # sintaxis de instancia

member a.MethodName 

este es muchas cartas y x se usa de otra manera.

+0

Vea también otras respuestas aquí: http: // stackoverflow.com/questions/1793484/should-i-use-this-self-or-something-else-for-self-identifiers-in-type-definitio – Stringer

Respuesta

7

uso casi siempre x como el nombre instancia. No hay lógica detrás de eso, aparte del hecho de que es más corto que otras opciones.

Las opciones que he visto son:

member x.Foo  // Simply use (short) 'x' everywhere 
member ls.Foo // Based on type name as Benjol explains 
member this.Foo // Probably comfortable for C# developers 
member self.Foo // I'm not quite sure where this comes from! 
member __.Foo // Double underscore to resemble 'ignore pattern' 
       // (patterns are not allowed here, but '__' is identifier) 

La opción basada en el nombre del tipo tiene cierto sentido (y es bueno cuando estás anidar expresiones objeto dentro de un tipo), pero creo que es podría ser bastante difícil encontrar dos/tres abreviaturas razonables para cada nombre de tipo.

+1

Siempre hay 'me.Foo', después de VB.NET. Yo uso 'x' o 'esto'. –

+0

'self' es Smalltalk, si no recuerdo mal. –

+1

Uso 'this' para no asustar a los programadores de C# mirando mi código. – gradbot

0

que tienden a utilizar algún tipo de siglas que representan el tipo de modo:

type LaserSimulator = 
    member ls.Fire() = 
3

No tienen un sistema. Me pregunto si debería tener uno, y estoy seguro de que algún día habrá un paradigma con su propio libro. Tiendo a usar primera (s) letra (s) del nombre tipo, como Benjol.

Este es un grado de libertad en F # del que claramente podríamos prescindir. :)

+0

a significa "tipo" en la mayoría de los lenguajes fp. Me pregunto si está bien usar, por ejemplo, miembros – napoleonss

+0

@napoleonss No conozco la mayoría de los lenguajes fp, pero tiene 'a (o' ) para indicar el tipo en F #; en ML también tiene '' a, etc., un identificador normal por sí mismo que puede usar como lo desee. –

+0

Sí, parece más coherente – napoleonss

1

que en gran medida tienden a usar self.MethodName, por la sola razón de que self representa la instancia actual, por convención, en el otro idioma más que utilizo: Python. Ahora que lo pienso, utilicé Delphi por un tiempo y tienen self en lugar de this.

He estado tratando de convertir a un estilo x.MethodName, similar a los dos libros que estoy aprendiendo a partir de: mundo real Programación Funcional y Experto F #. Hasta ahora no he tenido éxito, principalmente porque al hacer referencia al x en lugar de self (o this) en el cuerpo del método aún me confunde.

Creo que lo que estoy diciendo es que debe haber una convención significativa. El uso de this o self ya ha sido estandarizado por otros idiomas. Y personalmente no encuentro que la economía de tres letras sea tan útil.

0

La lógica que uso es esta: si no estoy usando la referencia de instancia dentro de la definición de miembro, uso un doble guión bajo ('__'), una expresión let-binding. Si estoy haciendo referencia a la instancia dentro de la definición (que no hago a menudo), tiendo a usar 'x'.

+0

Si no está utilizando la referencia de instancia, ¿no sería mejor que su definición de miembro fuera estática? Sería la sintaxis correcta para esta semántica, y eliminaría el identificador de instancia por completo. –

+2

@Alexander: No necesariamente. Por ejemplo, un valor se pasa a un constructor y se expone (posiblemente después de aplicar alguna función trivial) como una propiedad de solo lectura. No es necesario acceder a la instancia en la definición del miembro. Incluso si almacenara la entrada del ctor en un enlace privado, aún no necesitaría acceder al símbolo de identificación de la instancia ... y los datos siguen siendo relevantes para la instancia, no el tipo. – pblasucci

+0

@pblasucci No puedo ver el caso que mencionas, pero pensé que podrías estar usando otros métodos de instancia dentro del 'anónimo', así que sí, salté a una conclusión equivocada aquí ... (puedes ver tu texto ahora, parece que hay un error con el JavaScript aquí, así que sí, hay más de un caso donde esto tiene sentido). –

0

Como trabajo en el mundo de .NET, tiendo a usar "esto" en el supuesto de que la mayoría de las personas de .NET que encuentren F # entenderán su significado. Por supuesto, el otro lado de esa espada es que podrían tener la idea de que "esta" es la forma requerida.

.NET preocupaciones de auto-documentación aparte, creo que preferiría: "x" en general, o - como Benjol - alguna abreviación del nombre de clase (por ejemplo, "st" para SuffixTrie, etc.).

+0

tanto IronPython, IronRuby, VB.NET, F # y más son lenguajes .NET y ninguno usa 'esto'. ¿Me hiciste C# world? –

+0

Sí, lo siento, quise decir C#. ¡Aquí soy un defensor de mucho tiempo de la programación en varios idiomas bajo .NET y me encuentro alzado por mi propio petardo! Lol. La mayoría de los programadores de .NET que encuentro * son programadores de * C#, pero es una mala forma de mi asumir eso automáticamente, especialmente cuando soy un defensor de F #. – TechNeilogy

Cuestiones relacionadas