-
Notifications
You must be signed in to change notification settings - Fork 15
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
add link to return type #1
Conversation
Thank Jim - the tool was able to merge back the changes correctly for this one. So far so good. You want me to merge this in as-is? |
I'm not sure. Would you want to regenerate the stubs first for a comparison? |
The re-generated stubs looks the same as the changes you submitted. |
Yes. |
Or did you mean to just keep a running branch for all pull requests? Either way - just do it whatever way is better for you as it doesn't really have an effect on my workflow. |
# all of the entities in the active model, component, or group (if you are | ||
# within a group or component edit session.) | ||
# | ||
# @example | ||
# model = Sketchup.active_model | ||
# entities = model.active_entities | ||
# | ||
# @return [Sketchup::Entities] entities - the {Sketchup::Entities} of the current editing context, or Model{Model#entities} if none. | ||
# @return [Entities] The {Entities} of the current editing context, |
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.
Don't we need to use fully qualified identifiers? Sketchup::Entities
instead of Entities
? Or is just Entities
working for the stubs? (In which case I need to verify it works when generating from our C++ source)
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.
We should probably choose the fully-qualified identifier as a convention if only for consistency.
# | ||
# @return status - true if successful, false if unsuccessful | ||
# @return [Boolean] +true+ if successful, +false+ if unsuccessful |
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 most boolean type of return I think @return [Boolean]
is enough - the "true is successful is redundant". We only need to add as much info as needed.
# The transform! method is used to apply a transformation to a component | ||
# instance. | ||
# The +transform!+ method is used to apply a {Geom::Transformation} to a | ||
# component instance. |
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.
Why the indent?
@@ -477,8 +477,8 @@ def split(instance) | |||
def subtract(instance) | |||
end | |||
|
|||
# The transform! method is used to apply a transformation to a component | |||
# instance. | |||
# The +transform!+ method is used to apply a {Geom::Transformation} to a |
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've started denoting all references to classes and methods with the reference tag. In this case I would write:
The {#transform!} 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.
And on that topic I'm never been too keen on the "The method_name is doing x" way of introducing a method, I feel is echoing too much. However, it's used so consistently across the 1000+ methods already documented that there might not be any point trying to change that now?
I was thinking that contributors would make a pull request, which we'll then pull on our side and run the merge tool on. Then we'd close the PR. |
Fix SketchUp/ruby-api-docs#23