Consider adding decreaseAllowance() and increaseAllowance()

[GriffGreen]

Also taken from the Token Card Token Contract:

https://github.com/MonolithDAO/token/blob/master/src/Token.sol#L98

I'm not sure on the style choices but I do have a strong opinion on the name ;-) so i changed that. but i expect the other details might change as well. (like I hope to implement Dani's version of ds-math so we will use add() and subtract() instead of safeAdd() and safeSub())

The point of this addition to the contract is to avoid the race condition further by allow the UI to avoid using approve a second time... in fact, with these two functions, we can avoid using approve all together, but yet it can stay there for ol' times sake ;-)

    function increaseAllowance (address _spender, uint _addedValue) 
    onlyPayloadSize(2)
    returns (bool success) {
        uint oldValue = allowance[msg.sender][_spender];
        allowance[msg.sender][_spender] = safeAdd(oldValue, _addedValue);
        return true;
    }

    function decreaseAllowance (address _spender, uint _subtractedValue) 
    onlyPayloadSize(2)
    returns (bool success) {
        uint oldValue = allowance[msg.sender][_spender];
        if (_subtractedValue > oldValue) {
            allowance[msg.sender][_spender] = 0;
        } else {
            allowance[msg.sender][_spender] = safeSub(oldValue, _subtractedValue);
        }
        return true;
    }

[jbaylina]

Looks like the world is going to ERC223, so the approve will make no sense.

[Janther]

Not sure if ERC223 is a long term option though, since Vitalik himself doesn't approve and in the future, all addresses will be contracts regardless of them being or not a wallet.
Here is an response from @Dexaran to Vitalik speech.

https://medium.com/@dexaran820/response-to-vitaliks-speech-about-erc-23-ad240a27490f