Realización de un proyecto crowdsourced en Canvas - página 38

Nuevo comentario
 
Реter Konow:
El núcleo es la matriz. Contiene todas las propiedades de los objetos.

Puedes elegir tu método. Pero, en todos mis años de desarrollo de guías, he descubierto que ningún otro método puede proporcionar el mismo nivel de funcionalidad. La máxima simplicidad y eficacia es la perfección.


Peter, ¿tienes alguna experiencia y ejemplos de escritura de GUI no sólo en la versión actual?

Usted niega por completo otros paradigmas, pero afirma que su modelo es el mejor para la implementación de la GUI. Es una afirmación muy controvertida.

 

Realiza un indicador que corrija los ángulos de inclinación de las líneas dibujadas, sus puntos de intersección y las proporciones de las elipses. Mientras los puntos de anclaje se fijan en el futuro

después de dos fines de semana y algún maldito día indie...

PD/ da la sensación de que las personas que dibujan las interfaces no se dedican al comercio en absoluto

 
Maxim Kuznetsov:

Haz un indicador que corrija los ángulos de inclinación de las líneas dibujadas, sus puntos de intersección y las proporciones de las elipses. Con los puntos de anclaje fijados en el futuro

después de dos fines de semana y algún maldito día indie...

PD/ da la sensación de que las personas que dibujan las interfaces no tienen nada que ver con el oficio

Max, me atrevo a decir que en la mitad de los casos es así. El comerciante no tiene que ser un programador y el programador no tiene que ser un comerciante.

 

Me atrevo a decir que Pedro no programa en otra cosa que no sea mql. Todas las versiones modernas de lenguajes requieren conocimientos de trabajo con clases: java, kotlin, sharp, python, c++, etc. Incluso 1C tiene una apariencia de clases en forma de tipos de objetos fijos. Pero esto es sólo una digresión.

Desde mi punto de vista, el sistema de construcción de interfaces debería ser así:

CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY";
КнопкаBUY.ЦветФона = clrBlue;
КнопкаBUY.Позиция(7,20);
Форма.Добавить(КнопкаBUY);

Es decir, la creación de interfaces debe ser declarativa. No puedo ni imaginar cómo cualquier otro programador añadirá la descripción de las propiedades de un control que se refiere a los índices.....

Estoy seguro de que incluso para un programador medio sería desconcertante, por no hablar de un principiante.

 
Алексей Барбашин:

Me atrevo a decir que Pedro no programa en otra cosa que no sea mql. Todas las versiones modernas de lenguajes requieren conocimientos de trabajo con clases: java, kotlin, sharp, python, c++, etc. Incluso 1C tiene una apariencia de clases en forma de tipos de objetos fijos. Pero esto es sólo una digresión.

Desde mi punto de vista, el sistema de construcción de interfaces debería ser así:

Es decir, la creación de interfaces debe ser declarativa. No puedo ni imaginar cómo cualquier otro programador añadirá la descripción de las propiedades al tablero refiriéndose a los índices.....

Estoy seguro de que incluso para un programador medio esto sería desconcertante, por no hablar de un principiante.

Si hay muchos elementos y/o propiedades que dependen de un índice, no hay problema y viceversa, es difícil escribir un lío mientras se hace referencia a cada uno de ellos.

 
Roman:

Una matriz son bucles anidados, y los bucles anidados son tiempo. No estoy siendo sarcástico, sólo razonando con lógica.

Sí. Todo en el universo lleva su tiempo).
 
Алексей Барбашин:

1. Peter, obtienes lo siguiente: el núcleo consiste en una matriz global de propiedades de elementos, una matriz global de valores de elementos, una matriz global de dependencias, una matriz global de imágenes...

2. Si necesita añadir más propiedades, la dimensionalidad de las matrices aumenta.

3. Se accede a las propiedades estrictamente por índices, porque las celdas no tienen nombres.

Al menos se puede acceder a los nombres de los campos con la estructura.

Peter, tú... gigante...

Yo, por ejemplo, lo veo así (simplificado):

4. Una "clase" de facto es una cadena específica en su matriz global, sólo que con una cara más "humana". Las clases están diseñadas para crear sus propios objetos de datos, con un conjunto de propiedades comprensibles a las que se puede acceder por nombre en lugar de por índice. Una clase es sólo un constructor de tipo universal.

Así, creamos un control básico que contiene las propiedades más comunes, que casi cualquier control tiene.

Se pueden crear objetos especializados basados en él:

Es decir, cada tipo de control posterior simplemente complementa el tipo base con las propiedades requeridas.

Y puesto que, como he escrito antes, las propiedades básicas se almacenan en el control base, el recorrido de "golpear" el cursor en el control se hace comprobando un tipo de datos: CControl. Habiendo encontrado el objeto deseado, el programa tiene inmediatamente acceso a las propiedades de ese objeto, ya que el punto del programa ya está en el propio objeto, al igual que en su bucle el programa está en la línea del array deseado.

1. El núcleo es una matriz global. Dos dimensiones. El núcleo se construye mediante una función especial que lee un archivo en el que el lenguaje de marcas dice qué ventanas y elementos hay que crear.

2. No, la dimensionalidad de la matriz es constante. Sólo hay dos dimensiones.

3. Las propiedades de los objetos del núcleo están ordenadas. Cada uno tiene su propio índice. Los índices se nombran mediante definiciones. A medida que aumenta el número de propiedades de los objetos, la matriz se amplía. Hay formas de frenar su crecimiento y compactar los objetos de su interior.

4. La clase, como descripción del objeto, es buena, pero el mecanismo (que es el código) funciona más eficientemente con el núcleo. De todos modos, no importa. Se adapta a las necesidades de todos.

La descripción y el almacenamiento dispersos de las propiedades de los objetos (las principales en la clase base, otras en las descendientes) complican el acceso y el manejo. Si se añaden las limitaciones de visibilidad, los modificadores de acceso y el lenguaje ajeno, se consigue una verdadera reducción no sólo del mecanismo, sino del proceso de desarrollo. Sin embargo, esto es imho.
 
Реter Konow:
1. El núcleo es una matriz global. Dos dimensiones. El núcleo se construye mediante una función especial que lee un archivo en el que el lenguaje de marcas dice qué ventanas y elementos hay que crear.

2. No, la dimensionalidad de la matriz es constante. Sólo hay dos dimensiones.

3. Las propiedades de los objetos del núcleo están ordenadas. Cada uno tiene su propio índice. Los índices se nombran mediante definiciones. A medida que aumenta el número de propiedades del objeto, la matriz crece en anchura. Hay formas de frenar su crecimiento y compactar los objetos de su interior.

4. La clase, como descripción del objeto, es buena, pero el mecanismo (que es el código) funciona más eficientemente con el núcleo. De todos modos, no importa. Se adapta a las necesidades de todos.

La descripción y el almacenamiento dispersos de las propiedades de los objetos (las principales en la clase base, otras en las descendientes) complican el acceso y el manejo. Si se añaden las limitaciones de visibilidad, los modificadores de acceso y el lenguaje ajeno, se consigue una verdadera reducción no sólo del mecanismo, sino del proceso de desarrollo. Sin embargo, esto es imho.

No es nada complicado, esa es la belleza y el poder de las clases. Cada uno de los siguientes construye su funcionalidad basándose en la funcionalidad del objeto original. Como resultado, toda la funcionalidad básica (enfoque, clics, fuera del elemento, arrastrar y soltar, dibujar) - todo se implementa sobre la base de objetos básicos. El desarrollo y la modificación posteriores, el desarrollo de nuevos controles - todo esto no afectará a la funcionalidad básica, ya que se crea en el nivel de, por ejemplo, su lenguaje: el "núcleo" de la biblioteca. En este caso, los objetos tendrán exactamente los tipos de datos necesarios para una propiedad concreta.

"El núcleo se construye con una función especial que lee un archivo, donde se escribe en el lenguaje de marcas qué ventanas y elementos deben crearse". - esto es simplemente una tontería. Así que tienes una matriz que almacena todas las propiedades, y también tienes un archivo de marcado que especifica exactamente cómo debe leerse la matriz con las propiedades... "Los índices se nombran a través de defin iciones" - cada índice está conectado a una definición. La inserción aleatoria de un campo adicional hará que las propiedades se desplacen con consecuencias. "A medida que aumenta el número de propiedades de los objetos, la matriz crece en anchura" - a eso me refería con lo de la dimensionalidad (culpa mía, apliqué mal el término). Al crear el objeto de datos como una clase, se evitan todas estas complicaciones. Y esto es una verdadera complejidad, que no es realmente necesaria. Pero sabemos crearnos complicaciones para poder superarlas con éxito más adelante.

Y no tienes que crear clases jerárquicas y no tienes que usarlas en absoluto. Pero es razonable utilizar estructuras para deshacerse de hilos de datos innecesarios. IMHO

Peter, has hecho un gran trabajo al crear una biblioteca GUI en tu estilo. Pero si piensas publicar esto, igual vale la pena rediseñar todo a una tecnología diferente. Estoy dispuesto a ayudarte en esto y a transferir paso a paso todo el poder de tu biblioteca en una nueva dirección.

 
Алексей Барбашин:

No hay nada más complicado que eso, que es la belleza y el poder de las clases. Cada uno de los siguientes construye su funcionalidad basándose en la funcionalidad del objeto original. Como resultado, toda la funcionalidad básica (foco, clics, fuera del elemento, arrastrar y soltar, dibujar) se implementa sobre la base de los objetos básicos. El desarrollo y la modificación posteriores, el desarrollo de nuevos controles - todo esto no afectará a la funcionalidad básica, ya que se crea en el nivel de, por ejemplo, su lenguaje: el "núcleo" de la biblioteca. En este caso, los objetos tendrán exactamente los tipos de datos necesarios para una propiedad concreta.

"El núcleo se construye con una función especial que lee un archivo, donde se escribe en el lenguaje de marcas qué ventanas y elementos deben crearse". - esto es simplemente una tontería. Así que tienes una matriz que almacena todas las propiedades, y también tienes un archivo de marcado que especifica exactamente cómo debe leerse la matriz con las propiedades... Al crear su objeto de datos como una clase, se evita toda esta complejidad. Y estas son verdaderas complejidades que realmente no necesitas. Sabemos cómo crearnos complicaciones para poder superarlas con éxito más adelante.

Y no tienes que crear clases jerárquicas y no tienes que usarlas en absoluto. Pero es razonable utilizar estructuras para deshacerse de hilos de datos innecesarios. IMHO

Peter, has hecho un gran trabajo al crear una biblioteca GUI en tu estilo. Pero si piensas publicar esto, igual vale la pena rediseñar todo a una tecnología diferente. Estoy dispuesto a ayudarte con eso, y paso a paso mover todo el poder de tu biblioteca en una nueva dirección.

Sabes, he discutido tanto aquí sobre la aplicación de las soluciones propias y ajenas que estoy cansado de ello. )) Es que es muy cansado. Mi pensamiento está más adaptado a la matriz, el de otros a las clases... No vale la pena romper ninguna lanza.

Por lo general, tiendo a cambiar o simplificar las reglas, a desviarme del curso general, a hacer valer las mías sobre las ajenas. No puedes cambiarme.

Gracias por la oferta. Puedes seguir tu propio camino en el desarrollo de la guía. Ya lo he hecho a mi manera y no veo ningún sentido en repetirlo con un estilo diferente. Hay un lenguaje de marcado, un par de pasos para el editor de vis y alrededor de una semana para publicar. Todavía hay que rehacer la barra de tareas y corregir pequeños errores. Luego, usted dará su opinión sobre mi trabajo. Espero que sea útil para todos.

ZS. Después de la publicación, podré dar más detalles sobre las soluciones y puede ayudar a crear un análogo en las clases.
 
Реter Konow:
Sabes, he discutido tanto aquí sobre la aplicación de las soluciones propias y ajenas que estoy cansado de ello. )) Es que es muy cansado. Mi pensamiento está más adaptado a la matriz, el de otros a las clases... No vale la pena romper ninguna lanza.

Por lo general, me inclino a cambiar o simplificar las reglas, a desviarme del curso general, a hacer valer las mías sobre las ajenas. No puedes cambiarme.

Gracias por la oferta. Puedes seguir tu propio camino en el desarrollo de la guía. Ya lo he hecho a mi manera y no veo ningún sentido en repetirlo con un estilo diferente. Hay un lenguaje de marcado, un par de pasos para el editor de vis y alrededor de una semana para publicar. Todavía hay que rehacer la barra de tareas y corregir pequeños errores. Luego, usted dará su opinión sobre mi trabajo. Espero que sea útil para todos.

En tu caso no es una simplificación, sino una verdadera complicación. IMHO

1...313233343536373839404142434445
Nuevo comentario