Oleg Andreev



Software designer with focus on user experience and security.

You may start with my selection of articles on Bitcoin.

Переводы некоторых статей на русский.



Product architect at Chain.

Author of Gitbox version control app.

Author of CoreBitcoin, a Bitcoin toolkit for Objective-C.

Author of BTCRuby, a Bitcoin toolkit for Ruby.

Former lead dev of FunGolf GPS, the best golfer's personal assistant.



I am happy to give you an interview or provide you with a consultation.
I am very interested in innovative ways to secure property and personal interactions: all the way from cryptography to user interfaces. I am not interested in trading, mining or building exchanges.

This blog enlightens people thanks to your generous donations: 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo

Io suggestion

Based on hash table vs. message-receivers and activatable slot, not value.

1. Every slot is activated on direct access. Non-activatable slot access raises exception.

2. x := y creates getter method(getSlot(“_x”)) and setter method(v, setSlot(“_x”, v); v).

3. x = y is parsed as x=(y) (i.e. message x= with argument y).

4. No ::=operator.

5. Method definition: obj setSlot(“add”, method(x, self + x))

5.1. Method definition macro: obj def add(x, self + x) (could be implemented in Io itself)

Pros:

- cleaner setters and hooks for setters;
- smaller syntax;
- uniform message dispatch: each message is processed by a method;
- safety: no need to use getSlot(“x”) for method arguments when activatable value could be passed (relevant to any abstract algorithms).

Cons:

- performance hit since local variable access should perform double hash table lookup; this could be optimized by storing hidden variables (_x) in a plain array.

What do you think?