Mi enfoque. El núcleo es el motor. - página 14
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
El formato es sencillo, pero no funciona con él. Me refiero a cuando hay muchas propiedades en los objetos.
He aquí un ejemplo de su enfoque, utilizado realmente, los principios son los mismos. El análisis léxico del texto, es muy difícil de hacer manualmente. Sólo la automatización. Y no digas que es conveniente.
La matriz de prototipos mostrada es el resultado de la inicialización manual de las propiedades de los objetos con valores por defecto. Sólo lo ve el promotor.
Kernel principal: se compila automáticamente a partir de los prototipos de los elementos. A continuación, los prototipos se convierten en elementos concretos. También automáticamente.
En cuanto al trabajo con el constructor, hay palabras clave simples y una forma conveniente de dibujo. Allí no hay mesas de este tipo.
Aquí hay otro ejemplo que se ajusta a tu idea, sólo que con muchos elementos dinámicos. Hay estrategias enteras, tres de ellas en el ejemplo. No hay mucha comodidad aquí. En el archivo adjunto.
Es decir, para mantener la dimensionalidad del array, algunos de sus objetos tienen propiedades falsas. Es muy flexible, no se puede decir nada al respecto.
Por desgracia, tenemos que soportar temporalmente este inconveniente. Por otro lado, un núcleo bidimensional proporciona un acceso extremadamente cómodo y rápido, incorporando bucles y mucho más. Si haces un núcleo unidimensional, no habrá propiedades "falsas". Pero la comodidad será muchas veces menor. O bien, podría simplemente poner las propiedades de texto e icono en una serie de propiedades del núcleo. Y el problema será eliminado. Lo haré en el futuro.
Aquí hay otro ejemplo que se ajusta a tu idea, sólo que con muchos elementos dinámicos. Hay estrategias enteras, tres de ellas en el ejemplo. No hay mucha comodidad aquí. En el archivo adjunto.
En un principio he advertido a los lectores que mi enfoque no está dirigido a la comodidad de un programador. Estoy ofreciendo la concepción del desarrollo más potente y rápido de un programa.
Por supuesto, dirán que el desarrollo más rápido de un programa es enchufar bloques ya hechos. Sí, pero la calidad del programa baja y los gastos generales aumentan. Unir bloques no es la mejor solución en términos de eficiencia.
Al principio advertí a los lectores que mi enfoque no se centraba en la facilidad de programación. Ofrece el concepto de desarrollo más potente y rápido de un programa.
Es conveniente cuando el programador no modifica/crea directamente esos datos.
Utilizar un código que funcione con esos datos es bastante práctico.
Al principio advertí a los lectores que mi enfoque no se centraba en la facilidad de programación. Ofrece el concepto de desarrollo de programas más potente y rápido.
¿Cómo pueden coexistir estas dos disposiciones: la falta de comodidad para el programador y el desarrollo rápido de programas? ¿Cómo se puede desarrollar un programa rápidamente si no es conveniente?
¿Cuál es el problema de controlar? Añade una propiedad, y aumenta el tamaño de las filas del Kernel. Eso es todo.
¿Y qué hará si no es necesario hacer un botón rectangular, sino circular o triangular?
Si usas OOP, crearás una clase base Button, que tiene un método abstracto Draf - este método es responsable de dibujar los botones. Para un botón redondo, necesitarás crear un heredero de Button, que será suficiente para anular el método Draf, que implementará el dibujo del botón redondo. Para un botón rectangular, también bastará con crear un heredero de Button y anular el método Draf para dibujar un botón rectangular.
¿Cómo se vería todo si se utiliza su método?
Aquí hay otro ejemplo que se ajusta a tu idea, sólo que con muchos elementos dinámicos. Hay estrategias enteras, tres de ellas en el ejemplo. No hay mucha comodidad aquí. En el archivo adjunto.
¡No puede ser!
Es una cosa preciosa... es un autómata apilable.
con un conocimiento mínimo de ensamblador y Forth, es muy fácil de leer. Si hubiera comentarios, no sería más complicado que MQL.
Esto es útil cuando el programador no modifica/crea directamente esos datos.
Utilizar un código que funcione con esos datos es bastante práctico.
Verás que se crea un array de prototipos una vez. Y luego, se cambia MUY pocas veces. Sólo en caso de modificaciones graves en el programa.
¡No puede ser!
Es una cosa hermosa... una máquina de pila clara.
Si sabes ensamblador y Forth lo menos posible, se lee en un santiamén. Si hubiera comentarios, no sería más complicado que MQL.
Es un artilugio genial). Estás de acuerdo en que es más fácil escribir programas en MQL que en ensamblador. Hablo de usabilidad, de eficiencia.