Reconstant: Share constant definitions between programming languages | Hacker News Reader

Reconstant: Share constant definitions between programming languages

github.com

33 pointsnyellin18 comments

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.

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.

It's surprising to me that you think char arrays might be unfamiliar to C developers!

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.

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.

I don't know about C, but in C++ this is also not safe in a header file.

True. Putting that in a header file will lead to linker errors if the file is included more than once.

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

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.

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

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

Thanks, will look into both.

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

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.

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

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

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...

Environment variables don't give static type checking or autocompletion in your IDE.

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)

Reply on news.ycombinator.com