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

inspector: refactor to rename and comment methods #13321

Closed
wants to merge 1 commit into from

Conversation

sam-github
Copy link
Contributor

@eugeneo What do you think? Its "cosmetic" in some ways, but the renaming helped me understand the code better. I've a couple open questions, I'll comment on my own PR to point them out.

Pure refactor, makes no functional changes but the renaming helped me
see more clearly what the relationship was between methods and
variables.

  • Renamed methods to reduce number of slightly different names for the
    same thing ("thread" vs "io thread", etc.).
  • Annotated many local functions as static.
  • Added comments where it was useful to me.
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. dont-land-on-v4.x inspector Issues and PRs related to the V8 inspector protocol labels May 30, 2017
@@ -27,20 +27,36 @@ using v8_inspector::StringView;
template<typename Transport>
using TransportAndIo = std::pair<Transport*, InspectorIo*>;

std::string GetProcessTitle() {
// uv_get_process_title will trim the title if it is too long.
static std::string GetProcessTitle() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is inside an anonymous namespace, adding static doesn’t do anything here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I didn't notice that, I'll review all the statics for this (so you don't have to comment on each one).

Copy link
Contributor

@eugeneo eugeneo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing statics in anonymous namespaces will reduce the size of this patch.

@@ -39,6 +39,7 @@ class InspectorSessionDelegate {
public:
virtual ~InspectorSessionDelegate() = default;
virtual bool WaitForFrontendMessage() = 0;
// XXX SendMessageToFrontend() ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's ever be a need. And if we manage to make WS transport talk to inspector through the JS API then there will be only one InspectorSessionDelegate implementation, which will remove the need for this interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that I find "OnMessage()" to not clearly indicate the purpose, from the name it could be used to send messages either way, whereas SendMessageToFrontend() clearly indicates the direction of the message flow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Still hope to get rid of this interface soon :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I'll rename, only takes a minute, and I promise I will feel no sadness if you delete any of the renamed functions.

Copy link
Contributor Author

@sam-github sam-github left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commented on a couple more renamings/tiny refactorings I think would be worthwhile, but would like confirmation on. I could comment on every rename, but I hope they are mostly self-explanatory.

@@ -39,6 +39,7 @@ class InspectorSessionDelegate {
public:
virtual ~InspectorSessionDelegate() = default;
virtual bool WaitForFrontendMessage() = 0;
// XXX SendMessageToFrontend() ?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this rename would make meaning more clear.

@@ -559,21 +559,22 @@ static void init_handshake(InspectorSocket* inspector) {
settings->on_url = path_cb;
}

int inspector_accept(uv_stream_t* server, InspectorSocket* inspector,
// XXX(sam) shouldn't all these snake_case functions be CamelCase?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I misunderstand node naming conventions, but I thought C++ functions were supposed to be CamelCase, and only variables are supposed to be snake_case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class was a plain C as it was mimicking libuv conventions. Need to become proper C++ at some point...

@@ -58,7 +59,7 @@ class InspectorSocket {
struct http_parsing_state_s* http_parsing_state;
struct ws_state_s* ws_state;
std::vector<char> buffer;
uv_tcp_t client;
uv_tcp_t client; // XXX(sam) this is a server, why is it called "client"?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this confusing, it is a TCP connection, and it is connected to a "client" on the other side, but this side is the "server" side of the HTTP/Websocket connection. I'd suggest just calling it "tcp" (because it is a uv_tcp_t) or "socket" (because it wraps a socket).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tcp/socket - both sound good. Ultimately, I believe this field name came from libuv API uv_accept that calls the connection socket "client" as opposed to "server" that is a listening socket.

@@ -230,6 +242,7 @@ class SocketSession {

private:
enum class State { kHttp, kWebSocket, kClosing, kEOF, kDeclined };
// XXX(sam) why do these two methods have a trailing _? that's for properties
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo... AFAIR, they might've had _Io suffix at some point to signify they are called on IO thread.

class InspectorSocketServer {
public:
using ServerCallback = void (*)(InspectorSocketServer*);
InspectorSocketServer(SocketServerDelegate* delegate,
const std::string& host,
int port,
FILE* out = stderr);
// XXX(sam) why is loop not passed in ctor? Its fixed and known at that time.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I missing something? It seems like most of the state is passed in the ctor, and then some is passed in Start(), and I don't see why, is it just historical? Is there some future use-case this is designed around?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the part I want to cleanup the most. Did a couple of half-hearted attempts but never achieved the desired result. It is historical (this code started as a fork of old Debug thread) and also because creation and start were separate at some point (this code was a part of the inpsector Agent).

@@ -4010,8 +4010,8 @@ static void ParseArgs(int* argc,
}


static void StartDebug(Environment* env, const char* path,
DebugOptions debug_options) {
static void StartInspector(Environment* env, const char* path,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Legacy... when all the debug code was deleted this function was left with its old pre-inspector name.

class InspectorSocketServer {
public:
using ServerCallback = void (*)(InspectorSocketServer*);
InspectorSocketServer(SocketServerDelegate* delegate,
const std::string& host,
int port,
FILE* out = stderr);
// XXX(sam) why is loop not passed in ctor? Its fixed and known at that time.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the part I want to cleanup the most. Did a couple of half-hearted attempts but never achieved the desired result. It is historical (this code started as a fork of old Debug thread) and also because creation and start were separate at some point (this code was a part of the inpsector Agent).

@@ -230,6 +242,7 @@ class SocketSession {

private:
enum class State { kHttp, kWebSocket, kClosing, kEOF, kDeclined };
// XXX(sam) why do these two methods have a trailing _? that's for properties
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo... AFAIR, they might've had _Io suffix at some point to signify they are called on IO thread.

@@ -58,7 +59,7 @@ class InspectorSocket {
struct http_parsing_state_s* http_parsing_state;
struct ws_state_s* ws_state;
std::vector<char> buffer;
uv_tcp_t client;
uv_tcp_t client; // XXX(sam) this is a server, why is it called "client"?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tcp/socket - both sound good. Ultimately, I believe this field name came from libuv API uv_accept that calls the connection socket "client" as opposed to "server" that is a listening socket.

@@ -559,21 +559,22 @@ static void init_handshake(InspectorSocket* inspector) {
settings->on_url = path_cb;
}

int inspector_accept(uv_stream_t* server, InspectorSocket* inspector,
// XXX(sam) shouldn't all these snake_case functions be CamelCase?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class was a plain C as it was mimicking libuv conventions. Need to become proper C++ at some point...

@sam-github
Copy link
Contributor Author

ci: https://ci.nodejs.org/job/node-test-pull-request/8383/

@eugeneo @addaleax want to take another look? I backed out the statics.

void WaitForDisconnect();
void FatalException(v8::Local<v8::Value> error,
v8::Local<v8::Message> message);

// These three APIs called by the WS protocol and JS binding to create
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a typo/supposed to be are called by? (Also, I’d just say methods instead of APIs – at least to me a single API is usually a set of methods or similar things)

Copy link
Contributor

@eugeneo eugeneo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Pure refactor, makes no functional changes but the renaming helped me
see more clearly what the relationship was between methods and
variables.

- Renamed methods to reduce number of slightly different names for the
  same thing ("thread" vs "io thread", etc.).
- Added comments where it was useful to me.
@sam-github
Copy link
Contributor Author

ci was all green, I rebased and fixed the typo @addaleax commented on

@jasnell
Copy link
Member

jasnell commented Jun 1, 2017

New CI after rebase: https://ci.nodejs.org/job/node-test-pull-request/8417/

jasnell pushed a commit that referenced this pull request Jun 1, 2017
Pure refactor, makes no functional changes but the renaming helped me
see more clearly what the relationship was between methods and
variables.

* Renamed methods to reduce number of slightly different names for the
  same thing ("thread" vs "io thread", etc.).
* Added comments where it was useful to me.

PR-URL: #13321
Reviewed-By: Eugene Ostroukhov <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell
Copy link
Member

jasnell commented Jun 1, 2017

Landed in 26ab769

@jasnell jasnell closed this Jun 1, 2017
@sam-github sam-github deleted the inspector-name-refactor branch June 2, 2017 01:33
@sam-github
Copy link
Contributor Author

Thank you.

jasnell pushed a commit that referenced this pull request Jun 5, 2017
Pure refactor, makes no functional changes but the renaming helped me
see more clearly what the relationship was between methods and
variables.

* Renamed methods to reduce number of slightly different names for the
  same thing ("thread" vs "io thread", etc.).
* Added comments where it was useful to me.

PR-URL: #13321
Reviewed-By: Eugene Ostroukhov <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@jasnell jasnell mentioned this pull request Jun 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. inspector Issues and PRs related to the V8 inspector protocol
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants