26 lines
3.4 KiB
Markdown
26 lines
3.4 KiB
Markdown
|
```wmd-options
|
||
|
|
language = es
|
||
|
|
title_i18n = errors_manager_title_description
|
||
|
|
title_text = Descripción - ErrorsManager
|
||
|
|
```
|
||
|
|
|
||
|
|
<!-- [[wmd]] -->
|
||
|
|
|
||
|
|
El proyecto ErrorsManager es un proyeto ideado y desarrollado por Srx00 orientado a gestionar errores de una forma eficiente, compacta, sencilla y compatible entre plataformas. La idea radica en que la forma más simple de poder gestionar y mostrar errores de tipo global es gestionando un sistema Booleano que nos permite identificar punto a punto si algo es correcto o no, donde la solución más práctica, sencilla, eficiente, de bajos recursos y bajo peso sería el uso natural de binarios sobre valores enteros como valores comunes a todos los lenguajes, mediante la práctica del Bitwise y operadores binarios, ya sean nativos \(Como en la mayoría de los lenguajes) o alternativos \(Como es parcialmente en el caso de SQL Server), sin embargo, esto nos da un problema de funcionamiento real el cual podemos ver representado en la siguiente tabla:
|
||
|
|
|
||
|
|
[|
|
||
|
|
|= Lenguaje | Bits de entero | Bits de Bitwise seguros
|
||
|
|
| JavaScript | 32 | 31
|
||
|
|
| SQL Server | 64 | 28
|
||
|
|
| Python | Infinito | Infinito
|
||
|
|
|]
|
||
|
|
|
||
|
|
> [!!] Es cierto que Python no puede trabajar valores infinitos y que su valor máximo entero es de 64 bits, sin embargo, éste hace uso de una práctica que individualiza los dígitos del valor y los calcula en múltiples ciclos, que pese a ser un proceso más lento por ser fuera de la mantisa, aunque éstos se agrupon binariamente, permite un uso que puede extenderse hasta casi los 4GB de longitud, por tanto, hablando de semejantes longitudes lo consideramos, al uso de esta librería, como infinito.
|
||
|
|
|
||
|
|
> [!!] Es verdad que en los SQL el entero es de 32 bits, sin embargo, existe la variación del BigInt que nos permite tener enteros de hasta 64 bits. Es importante tener en cuenta que ciertos motores como MySQL/MariaDB no contemplan el uso físico de la mantisa pudiendo ser ejectados en entornos de 32 bits y poder trabajar valores de 64 bits, por lo que se cuenta únicamente por gestión de memoria, pero como uso serguro en decimal tenemos 64 bits, pero como uso Bitwise lo tenemos que bajar de 32 bits.
|
||
|
|
|
||
|
|
Visto este problema tanto de limitaciones como de diferentes longitudes de trabajo para los Bitwise existe esta librería. La idea es cambiar un valor numérico entero por un String cuya longitud se condiciona a los 2GB en la mínima \(32 bits de mantisa, pese a que éste sea realmente más, pero no en potencia 2 que serían los 4GB). También hay que tener en cuenta que el espacio asignado en lenguajes fuertemente tipados o de gestión de memoria, sería un despropósito asignar semejante cantidades, motivo por el cual, esta librería lo deja a una longitud de 512 bytes de tamaño para la gestión de errores. Dicha longitud se basará en Base64, base la cual sería una potencia 6 de base 2, es decir, por caracter tendríamos una gestión de 6 errores simultáneos distintos, por lo que 512 bytes daría lugar a la posibilidad de gestión de 512 \* 6, que vendría siendo **3072 errores simultáneos por String**.
|
||
|
|
|
||
|
|
> [!!] Esta librería permite alternar trabajo con Strings y valores numéricos enteros, siendo más eficiente y rápido, además de nativo, el uso de valores numéricos enteros positivos, así que se aconseja que mientras se esté por debajo de los 28 bits de longitud se haga uso de este sistema, a partir de ahí se aconseja el uso de Strings mediante esta librería.
|
||
|
|
|
||
|
|
<!-- [[wmd]] -->
|