29 comments

[ 4.2 ms ] story [ 76.1 ms ] thread
I would expect a more detailed breakdown of the individual parameters. The type, name, is it a pointer to type, etc. should all be in separate fields
Suggestion noted! I put this together today so there is definitely room for improvement.
Breaking up parameter name, and parameter type into two separate fields will be a good update.
What's the use case for this?
Seems like it must be to facilitate usage of whatever node's foreign function interface scheme is.
The name is node-ffi and yes, you are correct. Can also be used for automated documentation purposes.
I use something similar to generate API hooks for a large library.
A mess of regexes and splits... yeah, no. You should probably get introduced to the wonderful world of parsers (and compilers):

https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...

Please don't be rudely dismissive of new work, even when it seems that someone doesn't know much. The Show HN guidelines specifically emphasize this: https://news.ycombinator.com/showhn.html.
Alright. Sorry, that might have sounded a bit rude, but the intention was pointing OP the right way.
This is a bad name, another cproto library has been in use for over 20 years:

http://invisible-island.net/cproto/cproto.html

You're right, that's kind of why I named the bash command 'proto' instead of 'cproto', but maybe that's not enough. Any suggestions? I'll change it later today.
I should step back some from it being a bad name... It's actually a great name, it just conflicts with an in-use library that does substantially the same thing for another platform.

Is there a convention where the 'node-' prefix is off-limits for any reason? I don't know if it's really any better but if this were 'node-cproto' I wouldn't have commented.

The other option would be to do some word-play name like 'domesticator'.

What happened to descriptive names like 'c2json'?
Nothing, that is also a great name.
I would recommend against using a generic greek prefix for a name of a very specific tool.
Would there be something that goes the other way? Given a JSON input generates C structs and efficient serialization/deserialization for given input? It could be useful for C++ too but generate classes instead. I'm aware of gsoap which did this for wsdl and generated code for use by SOAP xml clients and servers but not sure if anyone has done this for json
While it's not quite what you want (as the specification language is not JSON---it's more like C declarations), "protobufs" allow you to generate serializers and de-serializers in a number of languages.

http://github.com/google/protobuf

(comment deleted)