o-react-blue-typescript-not
v0.11.0
Published
Utilities for react-blue not depending on a pre-processor
Downloads
7
Readme
o-react-blue-typescript-not
This package contains o-react-blue
classes that do not require source code pre-processing
It's version number is the same as o-react-blue
, and both packages are intended to work together, but minimizing the burden of source code pre-processing to the bare minimum required by JSX
Any project using o-react-blue
will also use o-react-blue-typescript-not
, but it will probably have a smaller foot print, a faster loading time, a more simple configuration, less requirements and a much better maintainability experience
Documentation
http://o-programming-language.org/
The programs I write expect objects to have a consistent identity during the program execution, and source code manipulation utilities like Babel rarely preserve it
Probably there are a few good reasons to statically process a language like Javasccript, I just can't think of any that is required to run a js program and that it can't be achieved with dynamic, simple and executable js code
As an example, @haijindev/o-css can declare and load css in plain javascript without pre-processing, or even defining, any .css
file
Fun fact, what @haijindev/o-css does, it was possible and simple to do from the very first versions of javascript, at least a decade before libraries like sass
or less
were conceived, but it wasn't until the release of React
library that such a solution became thinkable
Yet another fun fact about the identity of objects
Here's a fun use of preserving the identity of objects during the whole existance of a program: electronic currencies
Say, 30 years ago, a system with hundreds of billions of records may not have been conceivable
Today, any regular database, even a relational database, might store that amount of records
Particularly, if the records are nothing more than sets of ids
Here's a very not sophisticated idea for an electronic currency:
- let every coin have a unique, immutable id. A unique serial number
- let each user have a unique, immutable id
- let any user account be a set of unique coin ids
- let a transaction be to move one or more identified coins from a target set to a destination set
- let be a unique entity capable of creating new coins. Which is the same as creating new ids. No computational effort is required
- to allow offline transactions, let be a syncronization mechanism of choice between local, distributed sets of ids and a central entity to make its conciliation
Every coin having a unique id would allow offline transactions to be valid if, and only if, in both ends of the transaction the same coins are signed as moved from a target to a destination
To sign a transaction, the unique ids of both users and all of the unique ids of the coins would be used
To validate a transaction, the destination user may query if the signature of the target ids corresponds to the ids held in that account. The query would not be does this user have enough funds to make the transfer?
but, does the user account hold the concrete coins he's about to transfer?
Therefore, a user could not claim neither that he owns an abstract amount of money, nor that other user transferred him an abstract amount of money. Only that another user transferred him a concrete set of ids, and to prove it he would need to know the particular ids of the coins and to posses the correct signature for having them
In the film Superman IV, the villian works for a bank and gets rich by transferring the rounding pennies, unclaimed left-overs of valid transactions, to an account of his own
If every penny would have had a unique id, he would had get caught
I don't think a system can get more traceability of the money flow than having each coin to have a unique id, making frauds more difficult