Creating an Instance of a Class is a far better term for the creation of money but the idea of creating instances of dollars is only applicable in the frame that I propose for a monetary system composed of uniquely serialized digital dollars each with a unit value of one where the dollar is a fixed record an association to an owning account changes.
This link defines Instance
This link defines Class
Both links are definition of terms in Object Oriented Programming
Creating money as an instance of a class is an alien concept in the current monetary system. Money is not an instance of a Class Object called Money in the current system it is a number. A Number Object is an object wrapper for primitive numeric values.
Number objects are created with new Number().
In the debt money system new money is created when a loan is made. When a specific number representing the amount loaned is entered in the loan agreement. A lump sum of loaned money. One single number of variable numeric value stating the total amount of the loan. Payment on the loan is another numeric value stating a total amount that returns money to the nothing that it was created out of when the loan was made. Plus interest! Don't ask where that interest came from because there are a variety of explanations. If you want a good laugh at people twisting their knickers in a knot over the issue of where the money comes from to pay interest then go to this link. Nobody really knows. Some think they do. On the other hand, interest is really paid. However, interest is a side issue not the object of discussion here.
The point: Money at the working level in the current monetary system is nothing more than a variable lump sum numerical amount with properties of the Object Class: Number. What is called "Printing Money" in the current system is entering a variable number in a computer accounting record. Actually entering it to two balancing records: The Credit Record and the Debit Record. Funny thing here. Go to the Credit link at Wikipedia and you get an extensive explanation. Substitute "Debit" for "Credit" and you get nothing at that link! Ahh... the mystery of Balance Sheet Accounting in the Double Entry Book Keeping System. I hated it in high school, I still hate it. I hate the entire frame.
Creating Money in the monetary system I propose is creating each unique dollar one at a time by assigning it a unique serial number as an instance of the Class called Money. Money becomes independent of its purpose. Meaning exactly that money is not debt, a representation of debt. It has nothing to do with debt other than it is one of the things that can be done with money: loaned to someone or some financial entity to spend on something with a promise repay the loan. Otherwise money is money and when it is owned without relation to debt then it is by definition.....think about this.....it is debt free! Money in the system I propose was not born in debt nor in a lump sum.
My system gives money an identity beyond a number. It also gives it messages that it can respond to and carry out operations it knows how to do called methods. It is an object oriented system from its highest level of abstraction down to its lowest level of operation.
In the current system digital money must always have an associated account. It appears as as sum or balance in the account. This link explains the object oriented UML view of a bank account and the variable number balance attribute called money in it.
This from the beginning of that link: In this example money is a variable current value balance attribute of the object: "Account". The Account:State equals the Account:Balance.
Objects, Classes, and Packages
Object = Identity + Operations + Attributes
"An object is anything-- concrete or abstract-- that has
attributes and that can perform certain operations.
A typical operation might change one of the object's
attributes, calculate something, report an answer, and/or ask another object to
perform one of its operations.
We call the current values of an object's attributes its state.
For example, a bank account is an object that performs three
operations:
account.withdraw(25.25);
account.deposit(32.18);
account.getBalance();
account.deposit(32.18);
account.getBalance();
The account performs the first operation by deducting $25.25
from its balance, and performs the second operation by adding $32.18 to its
balance. We can think of the balance as the account's state:
account.balance
The account performs the last operation by reporting its
current balance to the operation's requestor."
Reversing the object and state roles of Account and Money Balance makes Money the object and Account the variable state attribute "Balance". An instance of the Object:Money is a uniquely serialized single digital dollar with a value of one. Its "Balance" attribute variable is only one thing and that is an associated specific unique current Money Supply Financial Entity user account number. Current account "Balance" state is a variable user account value Money Supply Financial Entity user account number but the Object:Money must always have a relationship to a single unique stated (state) Money Supply Financial Entity user account number. A one to one exclusive relationship at the unique instance of an entity level for two different instances of an object. One being Money the other being Account.
The account number that the Object:Money has a relationship to is the Money Supply Financial Entity account number. A number to which any and all associated related unique bank accounts are mapped that represents the associated Money Supply Financial Entity that "owns" that dollar and has access to control of that dollar through its bank account to change ownership from current owner to new owner of the unique digital dollar instance of the Object:Money
While account is a state relationship to the Object:Money in the total debt free centrally managed money supply system it is also a variable sum total state called Account:Balance of Object:Account at the bank account level. The total of all state balances of all accounts that relate to (are mapped to) the consolidating master account of the unique financial entity at the Money Supply level must always equal the sum of all unique serialized digital dollars associated with the same unique Money Supply Financial Entity account state at the Total Money Supply level.
At the Total Money Supply level Class:Money always knows its total state value sum balance. Instances of the Class:Money always know their related Money Supply Financial Entity and the total sum of all instances of the Class:Money having the same Money Supply Financial Entity Identifier. That sum always equals the sum of all bank accounts related to that unique Money Supply Financial Entity.
Bankers would be horrified by this system which gives Money an Object Identity instead of only a state in a bank account. It is an accountable debt free money structure.
From the prior link example of UML:
Alternate View making Money an Object, Account a State:
The UML icon for the Money class:
We can also show the attributes and operations:
|-----------------------------|
| Money |
|-----------------------------|
| balance: Account |
|-----------------------------|
| Change (amt: Account)|
|-----------------------------|
Class:Account is a very common example used in Object Oriented Programming tutorials. Simply google: Object Oriented Class Account to find examples to any degree of complexity in a variety of object oriented languages including the design language of UML.
Not many examples of using Object Class:Money. Money is not an object in the current money system. It is a state of the Object:Account called: Balance.
From the prior link example of UML:
UML Class, Object, and Package Icons
The UML icon for the Account class:
We can also show the attributes and operations:
Sometimes, if we are feeling lazy or lack details, we simply
write:
UML icons representing instances of the Account class (i.e.,
account objects):
Alternate View making Money an Object, Account a State:
The UML icon for the Money class:
We can also show the attributes and operations:
|-----------------------------|
| Money |
|-----------------------------|
| balance: Account |
|-----------------------------|
| Change (amt: Account)|
|-----------------------------|
Class:Account is a very common example used in Object Oriented Programming tutorials. Simply google: Object Oriented Class Account to find examples to any degree of complexity in a variety of object oriented languages including the design language of UML.
Not many examples of using Object Class:Money. Money is not an object in the current money system. It is a state of the Object:Account called: Balance.
No comments:
Post a Comment