-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Added documentation for APIs in System.Net namespace introduced in 2.x #3280
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
Conversation
@carlossanlop @mairaw @rpetrusha |
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.
Thank you @jozkee. Great changes. I left a few suggestions for you.
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.
behavior is correct; feedback is all about phrasing.
xml/System.Net/IPAddress.xml
Outdated
If the length of `address` is 4, this method constructs an IPv4 address; otherwise, an IPv6 address with a scope of 0 is constructed. | ||
|
||
The byte span is assumed to be in network byte order with the most significant byte first in index position 0. |
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.
Should these be documented in the param
rather than remarks
?
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.
+1
This is an interesting suggestion. We should always keep in mind that remarks do not show up in intellisense, so if we add this information at the end of the param, we ensure developers have this information available first hand.
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.
That's one reason, but also these remarks are all specific to the one param.
xml/System.Net/IPAddress.xml
Outdated
<summary>To be added.</summary> | ||
<returns>To be added.</returns> | ||
<param name="ipString">A character span that contains an IP address in dotted-quad notation for IPv4 and in colon-hexadecimal notation for IPv6.</param> | ||
<summary>Converts an IP address represented as a character span to an IPAddress instance.</summary> |
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.
Do we use the language "converts" elsewhere in docs when we are parsing a 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.
@scalablecory It is used in the other method signature, also it is used in IPEndPoint.Parse
and basically in any other type, int
in example
<param name="bytesWritten">To be added.</param> | ||
<summary>To be added.</summary> | ||
<returns>To be added.</returns> | ||
<param name="destination">When this method returns, the IP address as a span of bytes.</param> |
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.
<param name="destination">When this method returns, the IP address as a span of bytes.</param> | |
<param name="destination">When this method returns <see langword="true" />, receives the byte representation of the IP address in network byte order.</param> |
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 agree but shouldn't it be "contains" instead of "receives"? I also agree on the "When this method returns <see langword="true" />
" part but that is not the pattern that other TryParse
APIs follow.
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.
"contains" to me is a little confusing because it sounds like a precondition to calling this method. "receives" tells me it will have the IP address written to 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.
@mairaw thoughts on true vs langword true?
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 don't think we need to say contains. So what happens when the method returns false?
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.
@mairaw if TryWriteBytes
return false, it means that it didn't write into destination
.
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.
thoughts on true vs langword true?
@scalablecory Your suggestion is correct: we should use <see langword="true" />
instead of just true.
+1 What @mairaw said: We should mention what the contents of destination
will be if the method returns false
.
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'd be okay leaving without true or false as well. I just wouldn't say
"When this method returns true, ..."
I'd simply say "When this method returns, "
People should be checking the result of the method anyway before trying to use these, I'd say
<summary>To be added.</summary> | ||
<returns>To be added.</returns> | ||
<param name="destination">When this method returns, the IP address as a span of bytes.</param> | ||
<param name="bytesWritten">When this method returns, the number of bytes written into the span.</param> |
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.
<param name="bytesWritten">When this method returns, the number of bytes written into the span.</param> | |
<param name="bytesWritten">When this method returns <see langword="true" />, receives the number of bytes written into the span.</param> |
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 don't think this suggestion is correct. bytesWritten
will always have a number, whether the method returns true
or false
. Usually these methods set this argument to 0
right before they return false
. If that's the case, there's no point in mentioning "When this method returns true|false".
What @jozkee wrote might be enough, if he can confirm that the method sets this to zero on failure.
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 prefer the original version better. So if it's simply 0 when false, the original sentence still looks good.
Co-Authored-By: Maira Wenzel <[email protected]> Co-Authored-By: Cory Nelson <[email protected]>
<summary>To be added.</summary> | ||
<returns>To be added.</returns> | ||
<param name="ipString">The byte span to validate.</param> | ||
<param name="address">When this method returns, the <see cref="T:System.Net.IPAddress" /> version of the byte span.</param> |
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.
What happens to address
if the method returns false
?
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 is unchanged.
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.
LGTM. There are only a few comments to address related to the out params.
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.
@jozkee this looks good to merge, and the build passed without warnings.
Feel free to address or ignore this suggestion. You can also address it separately in a new PR.
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.
Addressing...
Documented APIs: