LBRYCommunity/lbry.go
1
0
Fork 0
Code Issues 5 Pull requests Packages Projects Releases 46 Wiki Activity

Defined lbryinc.Caller interface #63

Closed
anbsky wants to merge 1 commit from feature/lbryinc_client_caller into master
pull from: feature/lbryinc_client_caller
merge into: LBRYCommunity:master
Conversation 6 Commits 1 Files changed 2 +34 -10
anbsky commented 2019-07-10 21:10:00 +02:00 (Migrated from github.com)
Copy link

Defined lbryinc.Caller interface for easier drop-in replacement of lbryinc package in client code. This will help with testing and/or extending.

Note: I bumped minor version of the package because it introduces breaking changes in lbryinc package API.

Defined lbryinc.Caller interface for easier drop-in replacement of lbryinc package in client code. This will help with testing and/or extending. Note: I bumped minor version of the package because it introduces breaking changes in lbryinc package API.
nikooo777 (Migrated from github.com) reviewed 2019-07-10 21:10:00 +02:00
tiger5226 (Migrated from github.com) reviewed 2019-07-14 03:49:30 +02:00
extras/lbryinc/client.go
@ -17,0 +18,4 @@
SetServerAddress(string)
GetServerAddress() string
UserMe() (ResponseData, error)
}
tiger5226 (Migrated from github.com) commented 2019-07-14 03:49:30 +02:00
Copy link

ResponseData is a bad name. It should return UserMeResponse to conform to how we handle other clients with go. So that no fields of the response need to be parsed after the client has returned the response.

`ResponseData` is a bad name. It should return `UserMeResponse` to conform to how we handle other clients with go. So that no fields of the response need to be parsed after the client has returned the response.
tiger5226 (Migrated from github.com) reviewed 2019-07-14 03:51:27 +02:00
extras/lbryinc/client_test.go
@ -55,10 +55,17 @@ func launchDummyServer() {
log.Fatal(s.ListenAndServe())
}
func TestClient_Set_GetServerAddress(t *testing.T) {
tiger5226 (Migrated from github.com) commented 2019-07-14 03:51:26 +02:00
Copy link

should avoid underscores in go code method names.

should avoid underscores in go code method names.
tiger5226 (Migrated from github.com) reviewed 2019-07-14 03:54:26 +02:00
extras/lbryinc/client.go
@ -16,1 +16,3 @@
// Client stores data about internal-apis call it is about to make.
// Caller interface defines currently supported internal-apis methods.
type Caller interface {
SetServerAddress(string)
tiger5226 (Migrated from github.com) commented 2019-07-14 03:54:26 +02:00
Copy link

So when naming interfaces, those that end with an er should only have one method and it should be that remaining string. This is the convention for single method interfaces. So if you are naming an interface Caller it should only specify one method and it should be called Call.

So when naming interfaces, those that end with an `er` should only have one method and it should be that remaining string. This is the convention for single method interfaces. So if you are naming an interface `Caller` it should only specify one method and it should be called `Call`.
tiger5226 (Migrated from github.com) reviewed 2019-07-14 03:56:07 +02:00
extras/lbryinc/client.go
@ -19,2 +25,3 @@
serverAddress string
AuthToken string
Logger *log.Logger
logger *log.Logger
tiger5226 (Migrated from github.com) commented 2019-07-14 03:56:07 +02:00
Copy link

What is the purpose of making these private and adding methods? There is no special logic in the getter/setter to require it.

What is the purpose of making these private and adding methods? There is no special logic in the getter/setter to require it.
tiger5226 (Migrated from github.com) requested changes 2019-07-14 03:57:50 +02:00
tiger5226 (Migrated from github.com) left a comment
Copy link

Not blocking but definitely suggested.

Not blocking but definitely suggested.
extras/lbryinc/client.go
@ -65,0 +75,4 @@
}
// GetServerAddress returns currently defined internal-apis server address.
func (c Client) GetServerAddress() string {
tiger5226 (Migrated from github.com) commented 2019-07-14 03:57:27 +02:00
Copy link

I specifically like this pattern. Does it allow for specially configured logging per type?

I specifically like this pattern. Does it allow for specially configured logging per type?
anbsky (Migrated from github.com) reviewed 2019-07-15 13:59:50 +02:00
extras/lbryinc/client.go
@ -19,2 +25,3 @@
serverAddress string
AuthToken string
Logger *log.Logger
logger *log.Logger
anbsky (Migrated from github.com) commented 2019-07-15 13:59:50 +02:00
Copy link

Can't define properties on an interface.

Can't define properties on an interface.
lyoshenka commented 2019-07-15 15:10:57 +02:00 (Migrated from github.com)
Copy link

What's the purpose of having the Caller interface at all? Why not just have a straightforward api client?

What's the purpose of having the Caller interface at all? Why not just have a straightforward api client?
lyoshenka (Migrated from github.com) reviewed 2019-07-15 15:11:24 +02:00
extras/lbryinc/client.go
@ -16,1 +16,3 @@
// Client stores data about internal-apis call it is about to make.
// Caller interface defines currently supported internal-apis methods.
type Caller interface {
SetServerAddress(string)
lyoshenka (Migrated from github.com) commented 2019-07-15 15:11:24 +02:00
Copy link

I did not know this

I did not know this
lyoshenka (Migrated from github.com) reviewed 2019-07-15 15:16:34 +02:00
extras/lbryinc/client.go
lyoshenka (Migrated from github.com) commented 2019-07-15 15:15:52 +02:00
Copy link

why are Call and doCall two separate functions? i would either make them one function, or rename doCall to better describe what it does

why are Call and doCall two separate functions? i would either make them one function, or rename doCall to better describe what it does
tiger5226 (Migrated from github.com) reviewed 2019-07-16 03:55:20 +02:00
extras/lbryinc/client.go
@ -16,1 +16,3 @@
// Client stores data about internal-apis call it is about to make.
// Caller interface defines currently supported internal-apis methods.
type Caller interface {
SetServerAddress(string)
tiger5226 (Migrated from github.com) commented 2019-07-16 03:55:20 +02:00
Copy link

https://golang.org/doc/effective_go.html#interface-names for reference

https://golang.org/doc/effective_go.html#interface-names for reference
tiger5226 commented 2019-07-16 03:57:49 +02:00 (Migrated from github.com)
Copy link

Shouldn't breaking changes cause a major version change?

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

semver.org

Shouldn't breaking changes cause a major version change? ``` MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. ``` semver.org
anbsky commented 2019-07-16 18:03:58 +02:00 (Migrated from github.com)
Copy link

@lyoshenka

What's the purpose of having the Caller interface at all? Why not just have a straightforward api client?

It makes it easier to provide a mock client in tests that satisfies Caller interface. Currently to test my code that is using a concrete client I have to launch a fake http server that is providing predefined responses, which I'm not a fan of.

@lyoshenka > What's the purpose of having the Caller interface at all? Why not just have a straightforward api client? It makes it easier to provide a mock client in tests that satisfies Caller `interface`. Currently to test my code that is using a concrete client I have to launch a fake http server that is providing predefined responses, which I'm not a fan of.
lyoshenka commented 2019-07-16 18:37:04 +02:00 (Migrated from github.com)
Copy link

I have to launch a fake http server that is providing predefined responses,

that's actually the recommended way to do it in go. there's even a package for it: https://golang.org/pkg/net/http/httptest/

here's a simple example: https://stackoverflow.com/a/51227660

> I have to launch a fake http server that is providing predefined responses, that's actually the recommended way to do it in go. there's even a package for it: https://golang.org/pkg/net/http/httptest/ here's a simple example: https://stackoverflow.com/a/51227660
anbsky commented 2019-07-16 19:31:24 +02:00 (Migrated from github.com)
Copy link

@lyoshenka yeah, that's what I'm already using in my tests. Perhaps you're right and this complication is unwarranted here.

@lyoshenka yeah, that's what I'm already using in my tests. Perhaps you're right and this complication is unwarranted here.
tiger5226 commented 2019-07-18 04:46:29 +02:00 (Migrated from github.com)
Copy link

TIL about httptest

TIL about `httptest`

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
nikooo777
tiger5226
Labels
Clear labels   
area: devops

   
area: discovery

   
area: docs

   
area: livestream

   
area: proposal

Work is part of a proposal

  
consider soon

Discuss this issue at the next planning meeting, then remove this label

  
dependencies

Pull requests that update a dependency file

  
Epic

   
good first issue

   
hacktoberfest

Welcome to Hacktoberfest

  
help wanted

   
icebox

Long-term storage

  
level: 1

No knowledge of the existing code required

  
level: 2

Some knowledge of the existing code is recommended

  
level: 3

Significant knowledge of the existing code is recommended

  
level: 4

Intimate knowledge of the existing code is recommended

  
needs: exploration

Solution unclear, needs research

  
needs: grooming

Issue needs to be groomed before work can start

  
needs: priority

Priority level needs to be defined

  
needs: repro

Issue needs step-by-step instructions on how to reproduce in latest code

  
needs: tech design

Needs technical design signoff before implementation can begin

  
on hold

Temporarily paused

  
priority: blocker

Issue is blocking release, do ASAP

  
priority: high

Work needs to be moved into sprint ASAP

  
priority: low

Work should be done but can stay in the backlog for now

  
priority: medium

Work needs to be done within 2-3 sprints

  
resilience

   
Tom's Wishlist

   
type: bug

Existing functionality is wrong or broken

  
type: discussion

A conversation. No specific changes requested

  
type: improvement

Existing (or partially existing) functionality needs to be changed

  
type: new feature

New functionality that does not exist yet

  
type: refactor

Minimal user-visible changes, but significant internal work

  
type: task

Either work that's not related to the code, or a small chore that does not fit into other categories

  
type: testing

Solution needs additional user testing

  
unplanned

Work that was not planned into the spirnt, took priority over planned work

No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry.go#63
No description provided.
Delete branch "feature/lbryinc_client_caller"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?