5 ms·

Reconstant: Share constant definitions between programming languages

33 points by nyellin 6y ago

domano 6y ago
Environment variables do the job already, where is the benefit?
- rbarrois 6y ago
  I gather that this project targets internal constants. Let's say you need to share the list of error codes between your backend API and your frontend: instead of having to maintain two lists, just share the constants between the two codebases...
- choeger 6y ago
  You could also do this with the C-preprocessor or CMake config files. But a common, well-defined source language (here: yaml) should make it easy to add new backends and to adhere to language quirks (e.g., number literal formats)
- nyellin 6y ago
  Environment variables don't give static type checking or autocompletion in your IDE.
s_gourichon 6y ago
This might make sense for "big" projects, with already several languages and an important need. Else it's not obvious if the burden of having yet another dependency has a favorable benefit-cost result. In other words, the danger of "now you have two problems" should be considered. http://regex.info/blog/2006-09-15/247 http://regex.info/blog/2006-09-15/247
- nyellin 6y ago
  Always true! I've had this problem on several projects in the past decade and I always solved it with the easy solution of copy-paste. However, over the weekend I had an annoying bug in a personal project because the enums I had defined in the Vue frontend had accidentally changed from the enums I defined in the FastAPI backend... Thus Reconstant was born.
tempodox 6y ago
String constant generation for C is wrong. It should be const char X[] = "This string cannot be reassigned."; instead of const char *X = "This string CAN be reassigned"; In the second case, you can do X = "Another value"; X wouldn't be constant, but only the value it points to. Also, it costs sizeof(char *) more memory than the actual string contents.
- nyellin 6y ago
  Hmm, I'm torn on this. Using `const char* const` can solve the first issue. Regarding the memory, `const char X[]` is obviously better but it is a little less familiar to most developers. I'm not sure if it is worth saving the bytes as the cost of clarity.
  - cjaybo 6y ago
    It's surprising to me that you think char arrays might be unfamiliar to C developers!
    - nyellin 6y ago
      I should have been more clear. It's not that developers are unfamiliar with the string/array equivalence in C, but rather it's less common to encode constant strings that way and I've rarely seen it done. I can find data showing that adding the second const is uncommon. Here are the number of code results for different github searches: "const char " - 310 million results "const char" - 385 million results "const char * const" - 30 million results "const char* const" - 37 million results "const char *const" - 36 million results Unfortunately I'm not sure how to search for the array style syntax. One way or another, my point is that I'm more interested in optimizing for readablity and the way people expect things to be defined rather than the extra bytes.
      - s_gourichon 6y ago
        The better syntax being uncommon is not a reason to not adopt it. Sometimes the wide majority can be unaware of the better choice. I would rather see the change suggested as an opportunity to educate the developers.
yoav-lavi 6y ago
Interesting idea, I would suggest looking into TypeScript enum support as well as it is a different syntax than the JS object based variant (the const string definition can be shared) https://www.typescriptlang.org/docs/handbook/enums.html https://www.typescriptlang.org/docs/handbook/enums.html Edit: from the image it looks like you're using some non standard formatting for the JS output, using Prettier may be more standard - https://prettier.io https://prettier.io
- nyellin 6y ago
  Thanks, will look into both.
zffr 6y ago
To the OP, I’m just curious what was the problem you were facing that inspired this project? I haven’t run into a scenario where I would use something like this before
- nyellin 6y ago
  Sure. The short version is that this is for cases when you write frontend and backend code in different languages and they need to share constants. E.g. you might have an API in your backend called ExportData() which takes a parameter called ExportType that can be JSON_OUTPUT, TEXT_OUTPUT, CSV_OUTPUT, etc and you want to re-use those constants between the frontend and backend because they are often transmitted between the two. The long version is that I developed an application that runs on Kubernetes and can profile any Python application running in your cluster with no prior setup. (Useful if you want to debug a performance issue in an already running application.) My application has a Javascript frontend written in Vue.js and a Python backend written using the FastAPI framework. A user clicks a button in the frontend and chooses which process they want to profile and what type of profile it should be. (E.g. a regular flamegraph profile, a text file containing all the stack dumps, etc.) Then Vue initiates an API call to the backend. The backend checks what type of profile was requested and performs it for the client. I wanted to share the ProfileType enum between the frontend and backend. At first I just duplicated the constants by hand in Javascript and Python but I kept changing them as I added new features and got tired of syncing them by hand. Hope this helps explain the use.
whateveracct 6y ago
i just use Nix for this! define the constants in Nix, and generate the programming language files with simple Nix string programming.

33 points by nyellin 6y ago

domano 6y ago

Environment variables do the job already, where is the benefit?

rbarrois 6y ago
I gather that this project targets internal constants. Let's say you need to share the list of error codes between your backend API and your frontend: instead of having to maintain two lists, just share the constants between the two codebases...
choeger 6y ago
You could also do this with the C-preprocessor or CMake config files. But a common, well-defined source language (here: yaml) should make it easy to add new backends and to adhere to language quirks (e.g., number literal formats)
nyellin 6y ago
Environment variables don't give static type checking or autocompletion in your IDE.

s_gourichon 6y ago

This might make sense for "big" projects, with already several languages and an important need. Else it's not obvious if the burden of having yet another dependency has a favorable benefit-cost result. In other words, the danger of "now you have two problems" should be considered. http://regex.info/blog/2006-09-15/247 http://regex.info/blog/2006-09-15/247

nyellin 6y ago
Always true! I've had this problem on several projects in the past decade and I always solved it with the easy solution of copy-paste. However, over the weekend I had an annoying bug in a personal project because the enums I had defined in the Vue frontend had accidentally changed from the enums I defined in the FastAPI backend... Thus Reconstant was born.

tempodox 6y ago

String constant generation for C is wrong. It should be const char X[] = "This string cannot be reassigned."; instead of const char *X = "This string CAN be reassigned"; In the second case, you can do X = "Another value"; X wouldn't be constant, but only the value it points to. Also, it costs sizeof(char *) more memory than the actual string contents.

nyellin 6y ago
Hmm, I'm torn on this. Using `const char* const` can solve the first issue. Regarding the memory, `const char X[]` is obviously better but it is a little less familiar to most developers. I'm not sure if it is worth saving the bytes as the cost of clarity.
- cjaybo 6y ago
  It's surprising to me that you think char arrays might be unfamiliar to C developers!
  - nyellin 6y ago
    I should have been more clear. It's not that developers are unfamiliar with the string/array equivalence in C, but rather it's less common to encode constant strings that way and I've rarely seen it done. I can find data showing that adding the second const is uncommon. Here are the number of code results for different github searches: "const char " - 310 million results "const char" - 385 million results "const char * const" - 30 million results "const char* const" - 37 million results "const char *const" - 36 million results Unfortunately I'm not sure how to search for the array style syntax. One way or another, my point is that I'm more interested in optimizing for readablity and the way people expect things to be defined rather than the extra bytes.
    - s_gourichon 6y ago
      The better syntax being uncommon is not a reason to not adopt it. Sometimes the wide majority can be unaware of the better choice. I would rather see the change suggested as an opportunity to educate the developers.

yoav-lavi 6y ago

Interesting idea, I would suggest looking into TypeScript enum support as well as it is a different syntax than the JS object based variant (the const string definition can be shared) https://www.typescriptlang.org/docs/handbook/enums.html https://www.typescriptlang.org/docs/handbook/enums.html Edit: from the image it looks like you're using some non standard formatting for the JS output, using Prettier may be more standard - https://prettier.io https://prettier.io

nyellin 6y ago
Thanks, will look into both.

zffr 6y ago

To the OP, I’m just curious what was the problem you were facing that inspired this project? I haven’t run into a scenario where I would use something like this before

nyellin 6y ago
Sure. The short version is that this is for cases when you write frontend and backend code in different languages and they need to share constants. E.g. you might have an API in your backend called ExportData() which takes a parameter called ExportType that can be JSON_OUTPUT, TEXT_OUTPUT, CSV_OUTPUT, etc and you want to re-use those constants between the frontend and backend because they are often transmitted between the two. The long version is that I developed an application that runs on Kubernetes and can profile any Python application running in your cluster with no prior setup. (Useful if you want to debug a performance issue in an already running application.) My application has a Javascript frontend written in Vue.js and a Python backend written using the FastAPI framework. A user clicks a button in the frontend and chooses which process they want to profile and what type of profile it should be. (E.g. a regular flamegraph profile, a text file containing all the stack dumps, etc.) Then Vue initiates an API call to the backend. The backend checks what type of profile was requested and performs it for the client. I wanted to share the ProfileType enum between the frontend and backend. At first I just duplicated the constants by hand in Javascript and Python but I kept changing them as I added new features and got tired of syncing them by hand. Hope this helps explain the use.

whateveracct 6y ago

i just use Nix for this! define the constants in Nix, and generate the programming language files with simple Nix string programming.