waldronlab / waldronlab/bedbaser

Changing the API to use reference classes?

Open
#10 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
R
Stars
3
Forks
2
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names the current BEDbase() client and bb_list_beds(api) interface but no files or tests. Start by locating those entry points and reviewing how the client is passed to functions. Done requires a decided API design and an agreed implementation scope, which the issue does not yet define.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.