o-react-blue-typescript-not v0.11.0

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