class - programming - julia: OOP o no
lenguaje julia (5)
En caso de duda, lea la documentación ...
http://docs.julialang.org/en/release-0.4/manual/types/#composite-types
Larga historia corta:
type MyType
a::Int64
b::Float64
end
x = MyType(3, 4)
x.a
EDIT: los métodos se definen fuera de la definición de tipo, por ejemplo
function double(x::MyType)
x.a *= 2
end
Los métodos no viven dentro del tipo, como lo harían en C ++ o Python, por ejemplo. Esto permite que una de las características clave de Julia, despacho múltiple, funcione también con tipos definidos por el usuario, que están exactamente en el mismo nivel que los tipos definidos por el sistema.
Estoy trabajando en Juno con Julia.
No sé si Julia apoya OOP o no.
Por ejemplo, ¿hay algo así como class
o struct
de c ++?
¿Cómo declararlo con miembros como un dato o una función?
No soy un experto en el idioma, pero mi entendimiento es: sí ... y no.
Tiene el equivalente de clases y estructuras, sin embargo, no hay métodos en esos objetos además de un solo constructor.
En los lenguajes orientados a objetos convencionales, como C ++, Java, Python y Ruby, los tipos compuestos también tienen funciones nombradas asociadas a ellos, y la combinación se llama un "objeto". En los lenguajes más puros orientados a objetos, como Python y Ruby, todos los valores son objetos, ya sean compuestos o no. En lenguajes menos puros orientados a objetos, incluidos C ++ y Java, algunos valores, como los enteros y los valores de coma flotante, no son objetos, mientras que las instancias de tipos compuestos definidos por el usuario son objetos verdaderos con métodos asociados. En Julia, todos los valores son objetos, pero las funciones no se agrupan con los objetos en los que operan. Esto es necesario ya que Julia elige qué método de una función usar por despacho múltiple, lo que significa que los tipos de todos los argumentos de una función se consideran al seleccionar un método, en lugar de solo el primero (ver Métodos para obtener más información sobre métodos y despacho ) Por lo tanto, sería inapropiado que las funciones "pertenezcan" solo a su primer argumento. Organizar los métodos en objetos funcionales en lugar de tener bolsas con nombre de métodos "dentro" de cada objeto termina siendo un aspecto altamente beneficioso del diseño del lenguaje.
Me gustaría mencionar esta valiosa conversación dentro del grupo de usuarios Julia Julia y la Programación Orientada a Objetos .
Para mí, Julia no es como un lenguaje OO convencional, y siempre me gusta pensar que Julia, más como un lenguaje orientado a métodos que orientado a objetos , es porque si tratas de crear una estructura de datos encapsulados y funcionalidad en Julia, pronto te meterás en problemas.
Julia no está orientada a objetos en sentido completo porque no puede adjuntar métodos a los objetos de Julia ("tipos"). Sin embargo, los tipos parecen muy similares a los objetos. Sin embargo, dado que no tienen sus propios métodos asociados y no hay herencia, los objetos mismos no actúan. En cambio, tienes funciones que actúan sobre los objetos.
La diferencia es ball.checkCollision () vs checkCollision (ball, Walls). En realidad, no es un gran problema. Puede hacer que algo como herencia tenga un tipo que tenga un campo de otro tipo, y el despacho múltiple le permite escribir funciones que hacen cosas diferentes basadas en los objetos que le da, que pueden ser casi como métodos de objetos. La diferencia real es donde guarda la función y escribe en un archivo. Entonces puede hacer un tipo de estilo orientado a cuasi objeciones en Julia, pero sigue siendo claramente diferente de los lenguajes OOP.
Sí. Simplemente no puede heredar de "clases" concretas, solo de las abstractas.
Las funciones con despacho múltiple son una generalización estricta de los métodos con despacho único y son estrictamente más polimórficas. Solo tiene que definirlos fuera de una definición de clase, porque pueden "pertenecer" a múltiples objetos.
Los métodos tradicionales en un idioma OO son un caso especial de las funciones de Julia donde solo tiene despacho basado en el primer argumento.