Hi Lukasz, don't understand me wrong ... I would adjust the parsers to do that ... it would just be the way our generator-internal-model would keep track of it.
Problem is that for optional fields I need to generate the code differently (pointers to simple types instead of direct variables) So the "optional" would simply ensure the code is generated respecting that. Chris -----Ursprüngliche Nachricht----- Von: Łukasz Dywicki <[email protected]> Gesendet: Mittwoch, 25. August 2021 14:14 An: [email protected] Betreff: Re: [DISCUSS] Change the way we use "optional" I see a valid point to get optional block since way pointed by Ben causes creation of multiple wrappers. Assuming that we have nested optional fields: [type OptionalBlock [implicit uint 32 'length' 'COUNT(data)' ] [array int 8 'data' count 'length' ] ] [type DataBlock [uint 16 'size'] [optional OptionalBlock 'size > 0' ] ] After changes it would be: [type DataBlock [uint 16 'size'] [optional 'size > 0' [implicit uint 32 'length' 'COUNT(data)' ] [array int 8 'data' count 'length' ] ] ] I think that getting with optional flag under the hood will serve us near term. However long term solution should introduce optional as a block into our parser and generators. This will allow us to nest multiple optional sections. Otherwise we will shift problem just one level down. Since this is not a strong requirement for 0.9 we might plan this after we ship nearest release. Best, Łukasz On 25.08.2021 13:05, Christofer Dutz wrote: > Hi, > > as the discussion just came up on Slack ... taking it where it belongs > ... on the list ;.) > > So the problem was, that it's difficult to have anything optional that is not > a "simple" field. > > My Idea would be to change the way "optional" is used and to convert it into > a wrapper element. It would just contain an expression and contain normal > fields inside. > > So an > > [optional uint 8 "hurz" "some expression"] > > Would bebome: > > [optional "some expression" > [simple uint 8 "hurz"] > ] > > This way we could even wrap multiple elements inside the optional condition > and all of our types. > In general it would simply map to an if expression. > > I doubt the changes would be very significant. We would need to add an > "optional" flag to the internal field types and set that to false in the > general case but to true inside an optional field. > > Chris >
