Unpack should return an object

[cemsbr]

Refactor unpack methods to return the unpacked object instead of being an inplace method.

Probably the TODO creator meant implementing a class method so we would call FixedTypeList.unpack(buff), for instance.

[diraol]

@beraldoleal I don't think we will be able to reach this feature before kytos/python-openflow#198 and kytos/python-openflow#237.

[beraldoleal]

@diraol ok, no problem. b3 is a good target.

[cemsbr]

~~I was thinking about adding a class method from_bytes like Python int.from_bytes to be more pythonic. What do you think?~~

Edit: Some unpack methods rely on instance attributes (e.g. enum_ref). Thus, a class method won't work for all cases.

[erickvermot]

@cemsbr Why not use python's method directly to unpack instead of using struct, keeping '.value', etc.. that's what I proposed here: https://github.com/kytos/python-openflow/issues/198#issuecomment-316769379 https://github.com/kytos/python-openflow/compare/master...erickvermot:value_test (line 19 - https://github.com/kytos/python-openflow/compare/master...erickvermot:value_test#diff-83e119f254a95803fa6cdaff8bd5bee3R19)

[cemsbr]

@erickvermot, I think the pattern pack and _unpack, get_size and _get_size, etc is not the best OOP solution.

[erickvermot]

@cemsbr why not?

[cemsbr]

There's no need to create extra private methods. We can have only the public ones and children can override them if necessary.

[erickvermot]

@cemsbr Yes, you can, and this is the way it is done now. But this makes the derivative classes have to rewrite the docstring, and any other processing that is done prior to the actual packing action (like treating the optional arguments, or updating the length field in GenericMessages derivatives), which leads to massive amounts of redundant code, like in the current implementation. https://github.com/kytos/python-openflow/pull/392/commits/a4c1f0535d9e1a796c85785e525278a0e4490943 commit alone for example leads to a reduction of about 200 lines of code. If we decide not to accept optional value argument the reduction is even greater. The way I propose, (if needed) the user only needs to reimplement the actual packing action, and the user will remain calling pack in the normal way and will always have access to the docstring and other preprocessing without the need to worry about them.