Would you use a Replit API wrapper built in C/C++?

General
1

Would you use a Replit API wrapper built in C/C++?
I have immense experience programming and I’d be willing to take on a project like this if the interest and user group exists.
I was thinking I could wrap the GraphQL, Auth, and DB APIs for example in simple concise, and easy-to-understand functions.
If I was to build this, I’d build it modularly so that you only import the exact things you need.
Possibly add bindings so you can use it from other languages (like Python, JavaScript, etc) if you’d like.

  • Yeah!
  • Nah, but a good idea.
  • Nah, C/C++ is lame! Use something better!

0 voters

3 Likes
2

Ay! I’m all for this; I’m the one who ported the js ver to python :stuck_out_tongue: and I know c++

3 Likes
3

Thanks for your interest! I’ll consider doing this sometime soon.

1 Like
4

Yes, I’d use this (especially if I got to help and it worked in C).

2 Likes
5

Of course! It’ll definitely work over C also.
Planning to make it public domain so you shouldn’t have licensing issues.

2 Likes
6

Could be interesting actually

2 Likes
7

Yeah I’d love to see a map wrapper for the db, and a replapi-it port to c++!

1 Like
8

This wouldn’t be a port, but rather built from scratch.

1 Like
9

@youngchief Could you make a repl for a C/C++ Replit API library and add people?

2 Likes
10

… don’t think that’s a good idea since replapi-it has been honed for years

1 Like
11

It’d be far harder to copy JS into C/C++ than to just write a new library and stealcopy graphql queries from the old library

2 Likes
12

well I mean I have knowledge in the js ver, py ver, and would be able to help with this new one. The problem with new libs is there is a VERY specific and efficient way to effectively handle the data from replit

1 Like
13

Sure, but everyone has to agree to submit code under the public domain.

3 Likes
14

Library name?

  • libreplit
  • replit.h
  • replit.c

0 voters

15

Also, there are a lot of concepts that could be used to make a C/C++ library work better (e.g. allowing programs to request only certain data) that wouldn’t be implemented in the JS version.
For example, a C library could allow something like this:

#include <replit/replit.h>
#include <stdio.h>
int main(int argc, char* argv[]) {
  if(argv<2) {
    fprintf(stderr, "Not enough arguments.");
    exit(1);
  }
  struct replit_user *user;
  user = replit_getUserByUsername(argv[1], REPLIT_USERINFO_USERNAME | REPLIT_USERINFO_ID);
  if(!user) {
    fprintf(stderr, "Replit API error: %s\n", replit_errdesc(replit_errno));
    exit(1);
  }
  printf("%s has user id %d\n", user->username, user->id);
}
2 Likes
16

Woah, split decision. I’ll pick replit.h.
It’s designed to be as easy as #include "replit.h" to include it.

1 Like
17

That is one of the many reasons I wanted to code it in C/C++ and then have bindings to other languages.

18

I think libreplit would be good because then people could just use gcc -lreplit to link a binary with the API library, and it’d be easy to remember. (Also, I think using GNU autotools and libtool would be good, so it’d be easier to compile things with the library and compile the library on various systems)

1 Like
19

After thinking about it, I have made the initial channel #replit.h on YoungIRC (my IRC network). I plan to add other ways to join the conversation soon. Please use the chatroom for support, development, and other discussions related to Replit APIs and the library. You can find the source code here: YoungGit. Soon it’ll be mirrored to GitHub and other providers. I’ll expand with online documentation soon.

20

Well, you can just steal the queries without porting.

3 Likes