Pseudo Objects or Prototypes

Pseudo Objects work as Object in OOP programming but they are applied in a Procedural Structure. Which i called structural programming. Pseudo Object that we are using can be translated easily to object programming since they work the same. The diference in here they are all global so this represent our global_variables.h. The unic naming avoid name collision and help our global_functions to access it more easy. 

Our objects currently in development:

• -Text
• -Folder
• -Path
• -Link
• -File 
• -Error
• -Test
• -Font (still in dev)
• -String
• -Memory
• -History
• -Array
• -Loop
• -Login
• -Paginator
• -Effect
• -Menu
• -Settings
• -Translation
• -Window
• -Layer
• -Graphics
• -Position
• -Color
• -Space

When we access your "global_variables.h" file we should be able to see the variables prototypes for this topics. If you read on Objects and OOP oriented object programing you can read. The main issue is delegation. When a object is doing to much and other is  doing to less. The work and work in development is to balance this objects back and foward that they represent cleanly the task that they should deal.

In the interface we have several elements that we need to decompose in to p-objects:

-Menu
-Button
-Box (html for example, use: list, div, span, ul, etc...)
-Links

In here is not properly implemented is still in "property" which was a bit abstract but is a good example on how to implement objects. So it was a kind of to generic aproach to implement one of the refered elements. It become to big becase is not specific enought it will lead to bad programming. But still we can see the decomposition that is necessary in order to achieve prototypes.

int property_id;
int property_name;
int property_title;
int property_button;
int property_background_color;
int property_3d_model;
int property_padding;
int property_margin;
int property_pos_x;
int property_pos_y;
int property_pos_z;
int property_clickable;
int property_image;

...

button_image;
button_padding;
...
menu_image;
menu_padding;
...

A better way to do this is to manage only one property in this case "space".

• char space;
• char space_name;
• int space_type;
• int space_amount;
• char space_element;

For the background instead of puting a background in all items we can administrate width the color p-object.

• color;
• color_name;
• color_type;
• color_number_hex;

We are going to repeat our self's if we create a button, with background color, then a menu with background color, then a interface with background color and so on...

In this way we have a prototype for color which we can access and use at any time. Allow to programing width less knowledge. Any thing realtead width color\s it maps to the color object we don't need to search where the color is or study about color,s background and color connections.

The only draw back on this aproach it lead to more code in some parts not all since we reause, but is like unity tests that repeat code. Are they bad? like if you can program your app in 4 hours why do it in 8. But lather if you spend 3 days looking for a bug or 1 weak learning this new framework time can be over consume rapidly when things go wrong. In programming better play safe.