Primitive types after unpack and before pack

[beraldoleal]

We know that at the very early stage of development we decided to use boot: primitive types and our types on attributes. Ex: UBInt8() and int on an attribute of a generic struct subclass.

But using the library perhaps makes more sense to hide all the UBInt* stuff. So we should define the attribute as UBInt8():

class Foo(GenericStruct):
   a = UBInt8()

But when using makes more sense to use only integers:

>>> foo = Foo()
>>> foo.a = 8
>>> foo.pack()

The same should be done on unpack, and this is the most important part. Because when unpacking we should put there a python primitive value.

>>> foo.unpack(binary_data)
>>> type(foo.a)
(int)

The trick part is that in some cases (when is not primitive) we should accept only this complex type. Ex:

class Foo(GenericStruct):
   a = Header()

foo.a should only accept (before pack) only Header types.

We realized this when creating a new napp. The napp developer should not be aware of the lib internal types, like UBInt8()

Does that makes sense ?

[cemsbr]

Yes, agreed. pack() already works like this.

[diraol]

I also agree with this behavior, I think it makes the life of those who will use the library much easier.

Maybe even for us, developers of the lib, since we will have only one behavior, not two possible ones. It makes the lib much more consistent and avoid extra code checking.

As we want to do a refactor on the library to make the unpack method not behave as an inplace method, this two changes should be considered on the same moment.

[diraol]

@beraldoleal , the issue #237 was moved to "b3". Should we move this issue to that milestone? I'm asking because it make some sense to me to solve that issue prior to this issue.

Off course that this issue can be solved before #237, but it may add some duplicated work on the future depending on the #237 solution.

[beraldoleal]

@diraol sure.