Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿Qué afirmaciones en particular son infundadas?
hay suficiente.
El artículo es un artículo desechable, diseñado para obtener una tormenta de fuego de la gente de POO y no tiene nada que ver con mql porque simplemente no hay herramientas de lenguaje para FP en mql.
por lo que no tiene sentido discutirlo aquí.
hay suficiente.
El artículo es un lanzamiento, diseñado para ser quemado por la gente de OOP y no tiene nada que ver con mql, porque simplemente no hay herramientas de lenguaje para FP en mql.
por lo que no tiene sentido discutirlo aquí.
hay suficiente.
El artículo es un lanzamiento, diseñado para ser quemado por la gente de OOP y no tiene nada que ver con mql, porque simplemente no hay herramientas de lenguaje para FP en mql.
por lo que no tiene sentido discutirlo aquí.
Los comentarios son innecesarios.
Los defensores de FP olvidan conscientemente que su cálculo lambda es ejecutado por una máquina de Turing, con un número finito de estados y transiciones entre ellos, es decir, se utilizan los mismos contadores, instrucciones de bifurcación y goto. Por lo tanto, afirmar que FP proporciona algo más que los lenguajes clásicos como C, C# o Java es, como mínimo, incorrecto.
Vasily, este artículo te sería muy útil para no torturarte exprimiendo la OOP por la OOP.
Vasily, este artículo te sería muy útil para no torturarte exprimiendo la OOP por la OOP.
¿Por qué tan poco halagador? Me gusta mucho el estilo de sus artículos,
Me gusta el estilo y la limpieza de sus artículos, me gustaría que fuera limpio y legible - un nivel muy alto.
¿Por qué no es halagador? Me gusta mucho su estilo de escritura,
el código es limpio y legible - sin duda lo desearía para mí - el nivel es muy alto.
Lamentablemente no puedo apoyar esta conversación, no he leído ningún artículo ni he visto ningún código. Se trataba de otra cosa.
Desgraciadamente no puedo apoyar esta conversación, no he leído el artículo ni he visto el código. Se trataba de otra cosa.
Sólo puedo dar mi opinión acerca de la OOP para la claridad de la finalidad de la OOP en MQL. Terminé el código - era interesante ver lo que sería el resultado.
Ahora he envuelto todas las funciones para trabajar con los pedidos en una clase, y luego he limpiado el código y eliminado los parámetros en las funciones, ya que los campos de la clase son privados - sin sentido.... Tengo un código totalmente inutilizable para su uso posterior
Sí, es conveniente que puedas añadir pequeños métodos y extender la funcionalidad de la clase, pero para el uso futuro ... o añadir nuevos métodos sabiendo que el compilador no incluirá el código no utilizado en el ejecutable o... ... o ... escribirlas de nuevo - así que, en definitiva, tenemos un cierto monstruo de clase para trabajar con órdenes
es decir, la tasa de universalidad es un código hinchado que no podrás leer después de un par de meses y heredarás el código para no tener que averiguar lo que es superfluo en una clase - una pena para tu tiempo
en principio, puedes leer los nombres de los métodos según las tareas que vayas a ejecutar... en general, no estoy satisfecho con el resultado - todo es engorroso
Sólo puedo dar mi opinión sobre la POO para que se entienda la razonabilidad de la POO en MQL. Terminé el código - era interesante ver lo que saldría finalmente, al principio era la forma en que solía escribir - depurando funciones de servicio de trabajo con órdenes e insertando POO donde guardaba datos y pequeños métodos que pensaba usar sólo en una tarea determinada, llamaba a funciones de trabajo con órdenes de clases (estilo procedimental)
Ahora he envuelto todas las funciones para trabajar con los pedidos en una clase, y luego he limpiado el código y eliminado los parámetros en las funciones, ya que los campos de la clase son privados - sin sentido.... Tengo un código totalmente inutilizable para su uso posterior
Sí, es conveniente que puedas añadir pequeños métodos y extender la funcionalidad de la clase, pero para el uso futuro ... o añadir nuevos métodos sabiendo que el compilador no incluirá el código no utilizado en el ejecutable o... ... o ... escribirlas de nuevo - así que, en definitiva, tenemos un cierto monstruo de clase para trabajar con órdenes
es decir, la tasa de universalidad es un código hinchado que no podrás leer después de un par de meses y heredarás el código para no tener que averiguar lo que es superfluo en una clase - una pena para tu tiempo
en principio, puedes leer los nombres de los métodos según las tareas que vayas a ejecutar... en general, no estoy satisfecho con el resultado - todo es demasiado engorroso
En resumen, me cagué y me perdí.
En resumen: caga y vete.
Hmm, ¿quién salió? ¿De qué estás hablando? Bien... Todos sus comentarios en medio de la noche, es difícil saber qué es qué.
...
Y si no usas clases, te cansarás de escribir constantemente algo como SymbolInfoDouble(_Symbol,SYMBOL_BID). Siempre bailan los corchetes y los guiones bajos, y no sabes si pulsar el bloqueo de mayúsculas (y luego, en algún lugar sin mirar, escribir toda una cadena en mayúsculas y volver a escribirla) o mantener pulsada la palanca de cambios. Al menos ahí es donde la POO es útil. Si al menos se hacen clases para todas estas funciones, entonces sí - son enormes. Si lo escribes para ti, no hay problema. En cuanto al trabajo con las órdenes, no hay tantas funciones de uso frecuente, podemos simplemente poner algunas funciones en una biblioteca. Pero, en general, aún no existe un enfoque ideal.