search

google / emboss

Emboss is a tool for generating code that reads and writes binary data structures.
Apache License 2.0
68 stars 21 forks source link

Add design for alternate enum cases #83

Closed jasongraffius closed 1 year ago

josh-conner commented 1 year ago

I don't think of the constant syntax as an attribute of the data itself, but as an attribute of the environment where it will be used. Would it be possible to implement this as a command-line option?

jasongraffius commented 1 year ago

I don't think of the constant syntax as an attribute of the data itself, but as an attribute of the environment where it will be used. Would it be possible to implement this as a command-line option?

I do agree that the constant syntax/style/case can vary based on the environment, but I'd say it's also part of the data itself for a few reasons:

  1. The existing SHOUTY_CASE already binds a name/style to the data implicitly.
  2. Alternatives like packed structs are inherently binding a name/style to the data, and would require modifying the source to alter. This is also true of other serialization languages like protobuf.
  3. There can be name collisions in some cases, like the USB_1 vs USB1 example, and it would be difficult to resolve this in a command line argument alone.

That being said, I think an approach to support something like being able to have a file in a "canonical" format/style but set/override the style at build time could still be supported in future work by allowing build-time command line options to set/add/override attributes in the AST or the IR after parsing. I can open a new issue for further discussion on that if we want to discuss going down that route.

reventlov commented 1 year ago

I don't think of the constant syntax as an attribute of the data itself, but as an attribute of the environment where it will be used. Would it be possible to implement this as a command-line option?

I do agree that the constant syntax/style/case can vary based on the environment, but I'd say it's also part of the data itself for a few reasons:

  1. The existing SHOUTY_CASE already binds a name/style to the data implicitly.
  2. Alternatives like packed structs are inherently binding a name/style to the data, and would require modifying the source to alter. This is also true of other serialization languages like protobuf.
  3. There can be name collisions in some cases, like the USB_1 vs USB1 example, and it would be difficult to resolve this in a command line argument alone.

That being said, I think an approach to support something like being able to have a file in a "canonical" format/style but set/override the style at build time could still be supported in future work by allowing build-time command line options to set/add/override attributes in the AST or the IR after parsing. I can open a new issue for further discussion on that if we want to discuss going down that route.

I opened #85 for a feature that has been intended from when I first designed the attribute system: overlay files, so that you can add attributes without altering the original .emb file. That is out of scope for this feature.

jasongraffius commented 1 year ago

I opened #85 for a feature that has been intended from when I first designed the attribute system: overlay files, so that you can add attributes without altering the original .emb file. That is out of scope for this feature.

Excellent, I agree the .emboverlay system would cover that use case. I'll leave this discussion out of this design doc in that case.