-
Notifications
You must be signed in to change notification settings - Fork 96
refactor: address opencensus-core TODOs #47
refactor: address opencensus-core TODOs #47
Conversation
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
@@ -27,9 +27,6 @@ export class ConsoleLogger implements types.Logger { | |||
static LEVELS = ['silent', 'error', 'warn', 'info', 'debug', 'silly']; | |||
level: string; | |||
|
|||
|
|||
// TODO: reevaluate options to accept numbers as a parameter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each TODO that is removed without changes, please document (as a PR comment) why you decided not to do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll comment those. This one in specific was removed because being able to use numbers as parameters gives more freedom to the end user. Also, passing number as parameters is being currently used across the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks.
@@ -25,7 +25,8 @@ export interface Exporter extends modelTypes.SpanEventListener { | |||
* Sends a list of root spans to the service. | |||
* @param rootSpans A list of root spans to publish. | |||
*/ | |||
publish(rootSpans: modelTypes.RootSpan[]): void; | |||
// tslint:disable-next-line:no-any | |||
publish(rootSpans: modelTypes.RootSpan[]): Promise<any>|void; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two notes:
- What is the meaning of the deferred value being returned here? How are users expected to treat this value? If there are no good answers to this question it should just be
Promise<void>
. - Returning either a Promise or
void
complicates handling the return value. Can we only returnPromise
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ideia is that by returning Promise<any> | void
we account for publish
methods that returns a Promise, while giving freedom to future collaborators to make a method that returns void
. Currently, NoopExporter
and ConsoleExporter
return void, but if you prefer, I can change them to return Promise<void>
and restrict the interface, no problems with that IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's OK for publish
to inherently not contain anything asynchronous, but it would still be more consistent to return a Promise.resolve()
instead of void
anyway. If we consider the code that will call this function:
const result = exporter.publish();
if (result) {
result.then(next);
} else {
next(); // note: zalgo alert
}
Why even have this branching logic, when we could just do
exporter.publish().then(next);
That was the original context behind the second question. If you could make the change in *Exporter
that would be great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, got it. Made the change but had to make Promise<number|string|void>
to account for some exporter implementations that resolve number
or string
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Promise<number|string|void>
goes back to my original first question. Do we use the return value in a meaningful way? If so, it would be better to standardize now what that return value is (maybe a boolean or status code). Otherwise, if we don't use it, we should just make it void
.
BTW, the answer to this question might not exist today. It's hard to know how to standardize the return value if we are currently not using it. So I can merge this PR, just something to think about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could see the return value being used in tests only, but not in applications. I'm not sure if we should standardize it tho, goes back to that thing about future contributors. But I understand your point of view. Would be great to discuss that latter.
*/ | ||
abstract applyPatch( | ||
// tslint:disable:no-any | ||
moduleExports: any, tracer: modelTypes.Tracer, version: string): any; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are here... maybe it makes sense to parameterize the return value. We know the moduleExports
and the return value should be the same type, so we can make it applyPatch<T>(moduleExports: T, ...): T;
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes a lot of sense. As oc-core
changed since this PR was opened, I made this change to the enable
method.
"ts-node": "^4.0.0", | ||
"typescript": "~2.6.1", | ||
"nyc": "11.6.0" | ||
"intercept-stdout": "^0.1.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you preserve the alphabetical ordering here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
@@ -104,10 +101,6 @@ export class ConsoleLogger implements types.Logger { | |||
} | |||
} | |||
|
|||
|
|||
// TODO: reevaluate the need to create a new logger instance on every call to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By creating a new logger instance on every call to it we allow distinct classes to have distinct log levels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the original comment that this was in reference to is that every time logger
was called, the field logger['logger']
was being replaced. This field is also never getting read. The logger
method is otherwise just a call-through to new ConsoleLogger
.
I would prefer that logger
not even exist in the first place, and that anywhere it's used, new ConsoleLogger
is used instead. After all, why do we need the wrapper method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: #2 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My mistake, I got the TODO confused. Regarding this one, our idea here is to return an instance of logger, although calling new ConsoleLogger()
works too. We drove inspiration from this logDriver.
I removed the logger['logger'] = aLogger;
that had no need to be there at all.
5a6efe5
to
1a39e37
Compare
@@ -19,9 +19,6 @@ | |||
|
|||
import * as crypto from 'crypto'; | |||
|
|||
|
|||
// TODO: rethink this snippet aproach |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was no need for change here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some replies, what do you think?
Sorry for the delay. Took a look at your comments, thanks for reviewing. Made a few changes. |
394a12d
to
f807861
Compare
@eduardoemery Maybe you're in the middle of it right now, but currently the review comment changes only include |
d94f3ad
to
e044058
Compare
Yesterday morning I had some trouble with my git. Got it fixed but apparently it impacted here. Fixed now, sorry for the trouble caused. |
e044058
to
b64198a
Compare
const aLogger = new ConsoleLogger(options); | ||
logger['logger'] = aLogger; | ||
return aLogger; | ||
return new ConsoleLogger(options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Make this function have return type ConsoleLogger
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I used the interface types.Logger
instead of ConsoleLogger
to keep the pattern of using interfaces. But let me know if you don't agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
types.Logger
is better. Thanks!
b64198a
to
c580bfb
Compare
c580bfb
to
9c2523d
Compare
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) |
* refactor: changes to address opencensus-core TODOs * refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage * refactor(fix): changes to address review comments Co-authored-by: Fabio Silva <fgs@cesar.org.br>
* refactor: changes to address opencensus-core TODOs * refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage * refactor(fix): changes to address review comments Co-authored-by: Fabio Silva <fgs@cesar.org.br>
* refactor: changes to address opencensus-core TODOs * refactor: reveiw TODO for clearCurrentTrace when using continuation-local-storage * refactor(fix): changes to address review comments Co-authored-by: Fabio Silva <fgs@cesar.org.br>
No description provided.