Propuesta de Sintaxis para OOP en BennuGD

[JaViS]

Buenas!


me escribí rapidito lo que tenía en mente acerca de como debería implementarse OOP en Bennu (al menos en la parte de Sintaxis) y lo subi a la siguiente dirección:


Advertencia: esta escrito muy rapido y tiene muchos errores de ortografia, ni siquiera lo leí despues de escribirlo, y me quedó largo. https://medium.com/@javisarias/propuesta-de-sintaxis-para-oop-en-bennugd-227ebcc0da5


Me gustaría muchisimo que lo vean y lo discutamos por aca, asi aprovechamos que Juan anda con ganas de escribir un compilador nuevo :D

Pego el texto aqui también


Date: 2012-05-04
Title: Propuesta de Sintaxis para OOP en BennuGD

## Objetivos:

* mantener la compatibilidad con código no OOP
* posibilitar herencia de variables y metodos locales, privados y publicos.
* agregar la posibilidad de escribir métodos para nuestros procesos.
* que la palabra reservada TYPE retorne un listado de los procesos del tipo pasado por parametro y los que hereden de este.
* convertir a Process en el tipo básico de Objetos y que el resto herede de este.

## Idea basica:

La idea es convertir los procesos a objetos. Ahora mismo están muy cerca de serlo, tienen variables locales, publicas y privadas, e inclusive se crean instancias de un mismo tipo. Lo que necesitamos agregar es solamente herencia y métodos.

## Propuesta de sintaxis:
> **nota**: el código encerrado entre llaves {} es opcional

Como crear una nueva clase (tipo de proceso)


    process SoldierUnit(life) {extends Process}
   public
       int energy;
   begin
        {id.}energy = life;
   end

Como ven, la sintaxis para la creación de una nueva clase es identica a la creación de un nuevo tipo de proceso.
Como Process pasaría a ser la clase base en Bennu (que tiene la declaración de todas las variables locales por defecto) la sintaxis *extends Process* sería opcional en este caso. Esto significa que absolutamente todos los procesos heredarían de *Process*.

### Instanciar un objeto

Para instanciar un objeto de un determinado tipo lo haceríamos del mismo modo que creabamos procesos:

    character = {new} SoldierUnit(5);
   
Con OOP, al existir la superclase *Process*, podríamos hacer lo siguiente:

    character = {new} Process();
   
Esto crearía un proceso standard, con el constructor vacio y con las variables locales por defecto.

### Constructor

En OOP el Constructor es el método que se ejecuta al instanciar un objeto. En Bennu, esta funcionalidad corresponde con el bloque de código entre Begin y End de un proceso.

    process SoldierUnit(life)
    begin
        // este es el constructor
    end
   
Un constructor se ejecuta hasta llegar a la instrucción *frame* para continuar ejecutando el resto de los procesos. Por lo que nos aseguramos que el flujo de ejecución del programa sea identico al de Bennu actualmente.

### Funcionamiento de get_id() y TYPE:

get_id() se comportaría del mismo modo que ahora. Si hacemos:

    get_id(type SoldierUnit);
   
va a retornar instancias de la clase SoldierUnit, que es lo mismo que decir *"procesos del tipo SoldierUnit"*.

Parar retornar todos los procesos hacemos como antes:

    get_id()

que con OOP sería lo mismo que hacer:

    get_id(Type Process)
   
ambas formas deberían ser válidas.

### Miembros de la clase.

#### Variables (Propiedades).

Las variables de un objeto de declararían de la misma forma que ahora. Lo que hay que tener en cuenta aqui es que cuando declaramos variables con la palabra reservada *local* estaríamos agregando variables a la clase superglobal *Process* (Porque las variables locales afectan a todos los procesos y todos los procesos heredan de Proccess)

#### Metodos (funciones)

Los metodos de un objeto se declararían del siguiente modo:

    process SoldierUnit(life)
    public
        function damage(int points);
    end   
    begin // constructor
        id.damage(5);
    onexit: // destructor
    end
    function SoldierUnit.damage(int points)
    begin
        id.energy -= points;
    end
   
   

En el ejemplo el método se esta llamando desde el mismo objeto, *id*, permitiría, ademas de acceder a las variables propias de la instancia, acceder a los métodos de la misma.
Desde el método también deberíamos tener acceso a *id*. De hecho, el código dentro de un metodo deberia comportarse del mismo modo que si estubiera escrito dentro del bloque begin-end del proceso. Las funcion *collision()*, por ejemplo, identificar que fue llamada desde el proceso en cuestión.

Si el método se llamara desde otro objeto sería como en el siguiente ejemplo:

    player = SoldierUnit(5);
    player.damage(5);

Como es de esperarse :)

## Herencia

Como dijimos anteriormente, todos los procesos heredarían implicitamente de la clase *Process*. Pero también debería ser posible heredar de tipo de procesos definidos por el usuario.

Ejemplo:

    process RocketSoldier() extends SoldierUnit
    begin
    end

En el ejemplo, RocketSoldier heredaría la variable pública energy, y el método damage().

    soldier = RocketSoldier();
    soldier.energy = 100;
   
### Constructor

El constructor de un Proceso heredado sobreescribe al de la clase que hereda, lo que permite redefinir los parametros requeridos para crear una instancia de proceso. Sin embargo, se podría llamar a ejecutar el constructor de la clase madre desde el constructor del proceso hijo. En el ejemplo que venimos usando, RocketSoldier no tiene parametros, pero su clase madre SoldierUnit requiere uno (*life*). Para ejecutar el constructor de SoldierUnit desde RocketSoldier se haría del siguiente modo:

    process RocketSoldier() extends SoldierUnit
    begin //constructor
        // ejecuta constructor de la clase padre
        inherited(5);
        say(energy); // energy = 5       
        // ejecuta el metodo damage como fue declarado para la clase madre
        inherited.damage(5);
        say(energy); // energy = 0
    end
   
### Sobreescritura de Metodos

En la case hija se podría sobreescribir un metodo heredado, con la restricción de recibir exactamente los mismos parametros.

    process RocketSoldier() extends SoldierUnit
    begin //constructor
        energy = 5;
        // ejecuta el metodo damage como lo sobreescribimos
        damage(5);
        say(energy); // energy = 10
        // ejecuta el metodo damage como fue declarado para la clase madre
        inherited.damage(5);
        say(energy); // energy = 5         
    end
    function RocketSoldier.damage(int points)
    begin
        id.energy += points;
    end
   
### Funcionamiento de get_id() y TYPE:

Ahora que tenemos mas de un tipo de proceso definido, siendo uno herencia del otro, vamos a ver como la herencia toma sentido con el nuevo comportamiento de get_id() en el siguiente ejemplo.

    while (soldier = get_id(type SoldierUnit))
        soldier.energy--;
    end

En este ejemplo, get_id retornaría las instancias de SoldierUnit, como es esperado, pero tambien retornaría las instancias de RocketSoldier, ya que esta hereda de SoldierUnit.




Abrazos!!

[SplinterGU]

"new" no tiene sentido en un proceso... los procesos actualmente son eso, declaracion de tipo de procesos, no son un objeto unico... sino un tipo de proceso...

funciones dentro de un proceso podria ser...

luego lo de la herencia puede resultar un poco confuso...

[JaViS]

coincido que "new" no tiene razón de ser, ya que es como actua Bennu actualmente. Lo puse como una formalidad.


Pero lo de la herencia me parece la parte mas importante de toda la historia. OOP sin herencia no es OOP y estarías perdiendo la verdadera ventaja.

[SplinterGU]

algo se podria hacer... pero muy a futuro... primero tengo otras cosas que resolver...

igual es interesante el debate... sigan desarrollandolo.

[Rein (K´)ah Al-Ghul]

sera mi DNS, pero no logro ver el link...

[juansrx]

A mi me gustaría ver algo así, ya que con POO + patrones de diseño se podrían hacer cosas muy interesantes, sin embargo, me parece que sería más sencillo si Bennu fuera una serie de librerías y "plantillas" en C, para utilizarse dentro de código C/C++ (como era CDIV, donde "hackeando" un poquito el código de las librerías se podía saber como lograr la herencia de procesos.). Y de esta manera mezclar la abstracción que provee Bennu con el poder POO de C++ , sin nombrar lo que se podría hacer con otras librerías.

[SplinterGU]

A mi me gustaría ver algo así, ya que con POO + patrones de diseño se podrían hacer cosas muy interesantes, sin embargo, me parece que sería más sencillo si Bennu fuera una serie de librerías y "plantillas" en C, para utilizarse dentro de código C/C++ (como era CDIV, donde "hackeando" un poquito el código de las librerías se podía saber como lograr la herencia de procesos.). Y de esta manera mezclar la abstracción que provee Bennu con el poder POO de C++ , sin nombrar lo que se podría hacer con otras librerías.

tranquilamente podes llamar BennuGD desde C.

[JaViS]

sera mi DNS, pero no logro ver el link...

En un ratito lo arreglo

[JaViS]

A mi me gustaría ver algo así, ya que con POO + patrones de diseño se podrían hacer cosas muy interesantes, sin embargo, me parece que sería más sencillo si Bennu fuera una serie de librerías y "plantillas" en C, para utilizarse dentro de código C/C++ (como era CDIV, donde "hackeando" un poquito el código de las librerías se podía saber como lograr la herencia de procesos.). Y de esta manera mezclar la abstracción que provee Bennu con el poder POO de C++ , sin nombrar lo que se podría hacer con otras librerías.

Pues yo opino que, si bien lo que propones tiene sentido, no hay que olvidarse que Bennu (y Fenix y DIV en su momento) existen para que no tengamos que programar en C.

[KeoH]

Yo tambien llevo una temporada pensando en hacer a BennuGD mas orientado a objetos, lo de la herencia y los metodos me encanta y daría mas funcionalidades ..  aunque me parece confuso como has puesto la herencia JaViS, no lo he emtemdido xD .. lo de sobreescribir el constructor y lsobreescribir os metodos. Tambien estaría bien que los procesos pudieran heredar interfaces (que serían como una coleccion de metodos) porque los procesos pueden heredar a otro proceso, pero puede tener mas de una interfaz. Me gusta este debate xD


Splinter .. ¿ q planes tienes para Bennu a medio y largo plazo?

[Rein (K´)ah Al-Ghul]

Tambien tendria que haber algo como
System.out.say(string str)
que saque el contenido por consola

lo mismo para los set_mode y similares

System.Video.set_mode(int alto, int ancho, int densidadColor)

[SplinterGU]

Splinter .. ¿ q planes tienes para Bennu a medio y largo plazo?

por razones conocidas por todos, no puedo revelar que planes tengo para bennugd...

Tambien tendria que haber algo como
System.out.say(string str)
que saque el contenido por consola

lo mismo para los set_mode y similares

System.Video.set_mode(int alto, int ancho, int densidadColor)

esto definitivamente no seria bennugd... podria armarse un lenguaje diferente a bennugd, que genere bytecodes bennugd (o sea, que cree dcb compatibles)... de esta forma lo podria correr el runtime sin problema.

o sea, el motor de bennugd es un CPU virtual (aclaro, no compatible con ningun CPU conocido), asi como cualquier lenguaje genera codigo de maquina para los procesadores donde corre... podriamos hacer cualquier lenguaje que genere codigo de maquina BGD... incluso podriamos hacer un like java, que genere un dcb...

yo propongo que si alguien se anima, a que se diseñe un lenguaje nuevo (incompatible o no con bennugd) y que use el motor bennugd (generando dcb compatibles con bennugd), de esta forma incluso podriamos hacer avanzar el motor, pudiendo generar algunas cosas que actualmente no soporta y puedan ser utiles a nivel "codigo de maquina bgd"

[Transdiv]

Que interesante esto, seria algo asi como el Common Intermediate Language (CIL) del Net que es el target de muchos lenguajes, pero la infraestructura de ejecución es la misma. Aunque en este caso el assembler por asi decirlo de este CIL tengo entendido que ya es orientado a objetos.

[JaViS]

a mi me gustaría mantenerme, dentro de lo posible, en Bennu. Es por eso la propuesta, porque es un esfuerzo de mantener Bennu como es al mismo tiempo que posibilita lo mas básico y necesario de OOP

[Transdiv]

Splinter, el formato DCB esta documentado en algun lado o toca rascar los código fuentes para entenderlo?