pre-RFC: suggestion of Trits implementation

[wusyong]

@iotaledger/bee-devs With some conversation on #4, we should better start figuring out the basic layout of type Trits and open its RFC at the meantime. Here's proposal of @zesterer in trit's manner:

pub trait RawTrits {
    fn with_capacity(n: usize) -> Self;
    fn double_in_place(&mut self) -> bool;
    fn reserve(&mut self, used: usize, needed: usize);
    ...
}

pub struct RawTritPerByte {
    trits: ...,
} 

impl RawTrits for RawTritPerByte {

}

pub struct Trits<T: RawTrits>{
    raw: T,
}

impl<T: RawTrits> Trits<T> {
    pub fn new() -> Self {
        ...
    }
    
    pub fn with_capacity(n: usize) -> Self {
        ...
    }
    
    pub fn push(&mut self, x: Trits) {
        ...
    }
    
    pub fn pop(&mut self) -> Option<Trits> {
        ...
    }
}

So it can have default type something like struct Trits<T: RawTrits = RawTritPerByte> in this way. We still have a couple of questions remain and I would like to see if some one wish to take it and start a RFC with this.

• What trits encoding are we going to start first?
• Or should we implement both at once?
• How to do hashing with different encoding
• What method should we provide at least to defin in trait RawTrits?

[zesterer]

How to do hashing with different encoding

Hashing can be implemented on top of the high-level API (i.e: on the Trits struct). Alternatively, it could be implemented as a method on the RawTrits trait, with a default (but potentially slower) implementation provided. This way, encodings can override the default implementation if they have a more performant algorithm.

[thibault-martinez]

Some thoughts about this.

It seems like we are aiming at supporting the following trit encodings.

• 1t/1b - Raw trits
• 5t/1b - Mainnet wire
• 9t/2b - Potential Bee internal encoding
• 3t/1b - Trytes (the trytes type could actually just be a typedef on this)
• 27t/8b - Troika optimization
• ptrit - A little bit more challenging but makes sense

They should all share a common interface and should provide a way to convert from one to another.
This can easily be achieved by providing a toRaw and fromRaw methods.

[thibault-martinez]

3t/1b - Trytes (the trytes type could actually just be a typedef on this)

Trytes are an encoding of trits, 3 trits per byte. The question is if we want to make them an exception or have them as part of the trits interface.

Pros:

• Uniform API
• We only ever manipulate trits
• Removes the necessity to have functions like toTrytes in the trits API

Cons:

• Cryptic way to "name" trytes. Can be solved by aliasing it.

[thibault-martinez]

Regarding conversions from one to another we have two ways:

• fromRaw(toRaw(source)) - No addition needed, fully handled by the API, not optimized
• impl From<T> - Needs all combination implementation, optimized

[wusyong]

At this rate, do we still want an inner structure? I feel like they can be individual type with same trait.
Here's what I have in mind:

pub trait Trits {
    fn to_trits(n: &[u8]) -> Self;
    ...
}

pub struct 1TritPerByte {
    trits: ...,
}

impl 1TritPerByte {
    // Its own methods and can be public
    ...
}

impl Trits for 1TritPerByte {
    ...
}

[zesterer]

@wusyong While this is possible, it does mean that the raw Trits methods are publicly exposed. If this is a disadvantage we're willing to deal with, then that's fine.