more int format

[glelouet]

Features

Format class

A new IntegerRepresentation record contains information to represent int and long in the code.

Creation

A few default representation are available ; you are recommended to create your own.

// creation

// use default one, no separator
IntegerRepresentation myIR = IntegerRepresentation.DEFAULT;

// or default decimal one eg 1_000_000L
myIR = IntegerRepresentation.DEC;

// default hexa so 0xAB_CDL
myIR = IntegerRepresentation.HEX;

//specify all params
myIR = new IntegerRepresentation (false,
                                                                                 false,
                                                                                 EIntegerBase.DECIMAL,
                                                                                 0,
                                                                                 null,
                                                                                 0,
                                                                                 1,
                                                                                 true);

Usage

JAtomInteger and JAtomLong have that new field. They extend a common class that allows to manipulate those fields internally, replacing the representation each time.

// usage

var i = new JAtomInt(42, myIR);
i = new JAtomInt(42).representation(myIR)
// change the base to octal
i.octal()
// and add a separator every 3 char
.separateEvery(3)
// force the addition of +
.positiveSign(true);

Formatting process

1. formatting an integer/long uses a base and creates sign, prefix, body, suffix
2. sign only present if negative value or representation's positiveSign is true
3. prefix depends on the base selected. The representation's prefixUpper indicates if use upper or lower case prefix
4. body is converted from the base , then padded , then separated
5. suffix is only for LONG . The representation's suffixUpper indicates if use 'L' or 'l'
6. padded only applied for bases that use it. Decimal does not allow padding.
7. body separation is either performed with a separator format, or if null using the separateEvery and separateSize fields.
8. separator format indicates before which char, and how many, separators to add : each '_' indicates one separator to insert, starting from the end.
9. separateEvery indicates after how many body chars to add separator, and separateSize how many separator each time.

Padding example

(those are the tests)

42 padded 5 is

• 0b101010 (no padding needed here)
• 42 (can't pad decimal)
• 0x0002a (padding in hex)
• 000052 (padding in octal)

(those are the tests)

Separate Format example

1000 decimal with format

• "X_X" produces "100_0"
• "_xx__x" produces "1_00__0"

[phax]

I really don't think it is useful to provide all this customizability. Putting effort in creating code that is optimized for people but solely read by compilers is imho not a big priority...

[glelouet]

It depends. If you work on custom int format, you want to have eg the mask for the different part avail.
Say the format is SRC8_DEST8_BDY8_CRC4_TTL4 then you want to have the body mask
BDY_MASK= 000_00_77_0_0 ;

Also if you want to parse data to build other code from it, it may be better to parse the data faithfully.

[glelouet]

Anyhow, it's good it's not released, because I think it needs more thinking.

I will try to have common interface-ish for all number AtomX classes. Even though for example you have only dec and hex representation for fp.

I think I will go for a more complex internal field to represent the formatting, shared for long/int, and another shared for float/double . So IntegerLiteralFormat / FloatingPointLiteralFormat .

[phax]

But try to keep the default case (no formatting, decimal output) as efficient as possible - thx

[glelouet]

ok so here is what I want :

• be able to share the representation among several JAtomInt
• and also among JAtomLong (as in, same class for both)
• while still able to modify the JAtomInt individually

So for me it's best to have a record holding the representation params, including the enum base (hex, dec, bin, oct) , but have the already present methods visible on the JAtom to change the record to a new one.
This way we can directly set the whole params, or change then one by one ; and changing them won't impact the instances they are already assigned to.

[glelouet]

Much better this way. We can update the representation internally without changing the signature.
I had an awful lot of copypasta between int and long so I just made a common class. Thinking of it, could be an interface with default values. edit : no, it can't.

[phax]

fyi: I am on vacation next week - so no expectations towards me pls - thx :-)

[glelouet]

expectations

I did not expect you would review all the PRs so fast. gladly surprised.

Also it's nice you took the formatting. Will help me focus on the important things.

But yes, I don't expect anything, except that you take care of yourself during your vacations :)