On 5/15/14, Amir Taaki <genjix@???> wrote:
> Thanks. I'm not a fan of using abstract classes for this, templates are
> better (specialisation). But the factory idea is interesting. In the
> end, there seems to be no perfect design and integrating alts will
> involve some form of compromise.

You also have specialization with the concrete implementations of the
abstract class.
If you do templates, probably you want to implement them as
specialized templates for each currency instead of having a generic
one with switch statements or long and ugly elif structures.
You probably want the specialized implementations to be in different
files for readability.

At this point, it's probably a matter of taste.
If I'm not mistaken, compiler-wise an abstract class with different
implementations is equivalent to a generic template with specialized
templates.

It's a matter of deciding between:

class CurrencyClass {

    virtual int special() = 0;
    int common() {

       int spec = this->special();
       int toReturn = 0
       // do something
      return toReturn;
    }
}

class LiteCoinClass: public CurrencyClass {

   virtual int special(){
       int toReturn = 0
       // do something
      return toReturn;
   }
}

and

template<CurrencyType currencyType>
class CurrencyClass {

    int special(){
       int toReturn = 0
       // do something
      return toReturn;
   }

    int common() {

       int spec = this->special();
       int toReturn = 0
       // do something
      return toReturn;
    }
}

template<LITECOIN>
class CurrencyClass {

    int special(){
       int toReturn = 0
       // do something different
      return toReturn;
   }

    int common() {

       int spec = this->special();
       int toReturn = 0
       // do something
      return toReturn;
    }
}

I personally like the first approach more because it seems more
readable to me and you save the enumerated type, but I don't think
there can be convincing arguments either way apart from purely
taste/readabillity.

> ATM my targets are simply Litecoin and Dogecoin.

Fair enough, then you don't need the CMoney type for now.
Probably the differences between these two are so small that they can
all live in a ChainParams-like class (which only has constants and
maybe very simple formulas like reward from block height).
Obviously I'm biased towards Freicoin, which may be the only one that
requires a different behavior in the money type, that's why wanted to
help on that. But it makes sense to support altcoins with meaningless
changes like litecoin and dogecoin first (also with a bigger user
base).
I'm definitely interested in helping with Freicoin support if that is
considered in the future.

> On 15/05/14 10:29, Jorge Timón wrote:
>> I think one good approach is to have interfaces (abstract classes)
>> that are later extended with a concrete implementation for each chain,
>> much like the CChainParams class for the mainnet, testnet and regtest
>> modes in bitcoin-qt. You should be also able to discard some altchains
>> at compile time (maybe to avoid special dependencies).
>> That way the system can be compiled for all the alts and then run for
>> one of them specifying a parameter like has been discussed already.
>> Polymorphism will do the rest.
>>
>> The parts to move to interfaces depend a lot on the nature of the
>> currency itself.
>> For dumb changes like different inter-block times you're probably fine
>> with a chainparams class with static parameters.
>>
>> For different proof of work you probably need a pow abstract class too.
>>
>> There's currencies that may need to change the money type as well, for
>> example, Freicoin uses the GMP library's arbitrary-precision rational
>> number type for increased divisibility and interest calculations. See
>> this pull request on bitcoin-qt to replace uint64_t with a CMoney
>> type:
>>
>> https://github.com/bitcoin/bitcoin/pull/4067
>>
>> You could use templates for the concrete implementations of the
>> abstract class and then maybe use a factory pattern for instanciation.
>> Maybe you can get some inspiration on this old project of mine.
>> Here's an abstract class:
>>
>> https://github.com/jtimon/preann/blob/master/src/neural/buffer.h
>>
>> A concrete implementation for CUDA (with templates for the data type):
>>
>> https://github.com/jtimon/preann/blob/master/src/factory/cuda/cudaBuffer.h
>>
>> And the factory:
>>
>> https://github.com/jtimon/preann/blob/master/src/factory/factory.cpp
>>
>> With this you can discard implementations at compile time:
>>
>> https://github.com/jtimon/preann/blob/master/src/factory/configFactory.h
>>
>> I hope at least some of this is useful.
>>
>>
>> On 5/14/14, Amir Taaki <genjix@???> wrote:
>>> 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?
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


--
Jorge Timón

http://freico.in/