Hi Sebastian,

Just had another idea ... perhaps I misunderstood your intention behind the 
bitmask ... 
if this isn't intended to be a enum-like structure but a number of x Boolean 
fields?
If this is the case I strongly suggest to implement x bit simple fields.

Chris



Am 29.11.19, 11:38 schrieb "Christofer Dutz" <[email protected]>:

    Hi Sebatian,
    
    I just had a look at your mspec work … it seems in the AMSHeader type, you 
ran into a problem which I would like to help you with.
    
    The simple field:
    [simple     uint        32  '../data.lengthInBytes'        ]
    
    What should this field contain? I am asking as the mspec code doesn’t have 
a parent relationship so this will not work. However you can pass in data via 
type arguments.
    
    But for me it feels like perhaps refactoring the structure could eliminate 
problems.
    The general problem is that we need the “data” object to produce the 
output. So we would need this before parsing the header, which can’t happen as 
it hasn’t been parsed yet.
    One option would be to make this a normal property in the header and to 
reference this, if needed in the data. The downside would be that this might 
introduce double data.
    
    I would suggest to merge the AMSPacket and the AMSHeader.
    
    
    [type 'AMSPacket'
        [reserved   uint       16   '0x0000'            ]
        [implicit   uint       32   'totalLength'       'lengthInBytes - 6']
        [simple     AMSNetId        'targetAmsNetId'    ]
        [simple     uint        16  'targetAmsPort'     ]
        [simple     AMSNetId        'sourceAmsNetId'    ]
        [simple     uint        16  'sourceAmsPort'     ]
        [enum       CommandId       'commandId'         ]
        [enum       State           'state'             ]
        [implicit   uint        32  'dataLength'        'data.lengthInBytes']
        [simple     uint        32  'errorCode'         ]
        [simple     byte        32  'invokeId'          ]
        [simple     ADSData    'data'                   ]
    ]
    
    I know why you might want to model the header separately, but sometimes 
adjusting the structure to avoid complexities like this is a good thing to do.
    
    The other thing is your proposed “bitmask” … I can’t really see the 
difference between an enum and your bitmask.
    I think it shouldn’t be a problem to make the enum parser to understand the 
bit-pattern you propose (Which I really like, by the way).
    If you are worried that enums are in java not extendable, I would really 
like to change the enum code-generation to make extendable enum structures 
instead of pure java enums.
    
    What do you think about this?
    
    But I am happy that you seem to have generally grasped how to build mspecs 
which makes me really happy as I think you are one of the first to do that :-)
    
    
    
    
    
    

Reply via email to