Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing the API to use reference classes? #10

Open
nsheff opened this issue Oct 11, 2024 · 1 comment
Open

Changing the API to use reference classes? #10

nsheff opened this issue Oct 11, 2024 · 1 comment

Comments

@nsheff
Copy link

nsheff commented Oct 11, 2024

Given that the BEDbase() object is a client that connects to a server, it seems to me that this is an appropriate use of a Reference Class, because we don't really need duplicates of this object; we just need 1 client and then whatever functions use it can just use that.

It also makes more sense to me for the user to do something like this:

bb <- BEDbase()


bb$list_beds()

Rather than the current approach of passing the api in to the functions, like bb_list_beds(api).

This has the advantage that I can type bb$ ... and then tab complete and get REPL feedback as to what methods are available.

Maybe this is less idomatic for R, but I find this approach more intuitive and I think reference classes made this approach possible. Would love to hear your thoughts.

So I think the 2 advantages of using reference classes would be:

  • improved efficiency, since it wouldn't then require duplicating this client to use it?
  • cleaner user interface (in my opinion)

but I'm not super confident in all these things, so it's just an idea for consideration/discussion.

@jwokaty
Copy link
Collaborator

jwokaty commented Oct 11, 2024

I see your points and I headed down this path initially when I was writing bedbaser before it quickly became complicated for a handful of convenience functions I created in the package. I'll give it more thought but I am reluctant to change it close to the release when it's also in review, even though it would mean deprecating things later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants