Here's some experimentation by me to see how it could look in libbitcoin:

http://ideone.com/01YG2K

Notes:

* Every free function would become templated.
* I am looking for a way to avoid having different semantics for classes
to refer to values (currency_->some_value()) vs for functions
(Constants::some).
An option is to make classes templated too, and then libbitcoin would
become a nearly totally header only library (like the standard library).

On 14/05/14 17:13, mlmikael wrote:
> So now proper subject on this thread.
>
> On 2014-05-14 16:28, Thomas Hartman wrote:
>> I suppose
>>
>> sx --currency=litecoin
>>
>> with bitcoin default might work. This would be backwards compatible.
>
> Yeah, sx -c LTC / --currency=LTC would be nice , with BTC as default.
>
>> That being said, to me, this is only a really attractive option if all
>> the currency-specific code can be specified in an config file that is
>> read at compile time.
>>
>> I suppose this would be things like the genesis block, and scrypt vs
>> sha.
>>
>> Perhaps a similar mechanism could also be used to control whether
>> testnet or mainnet is specified.
>>
>> Maybe there is a way to distinguish testnet/mainnet with sx already
>> but I couldn't figure it out.
>
> At the end of the day I guess there will be some custom programming
> needed for an altcoin beyond a config file, because there will be some
> coin-specific logics and config files don't do logics.
>
> Perhaps an alternative to hardcoding those logics as a coin-specific
> class in LibBitcoin, then perhaps altcoin support could be located to a
> per-altcoin module implemented as
> * a dynamically loaded shared library, or as
> * a Javascript module delivered by V8, if that would work well with
> concurrency.
>
>
> For understanding the viability of modularization, there would be value
> in someone going through these various currencies and doing a systematic
> comparative documentation over algorithmic/technological similarity and
> difference.
>
> Since they tend to be BitcoinD forks, that ought to be quite
> straightforward, however I guess it would easily become a very big
> project, quite probably beyond what anyone wants to look into now -
>
>
>
>
> For overview presently, coinmarketcap.com tells us that BTC and LTC are
> the serious players, only. Therefore,
>
> * implementing LTC would be solid value, and
>
> * also perhaps, that it could be worth checking out in detail if/how
> altcoin support through modules would be workable
>
>
>
> Thoughts?
>
>
>