Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Fixing newlines
Comment | File | Size | Author |
---|---|---|---|
#22 | 855420-22.patch | 5.81 KB | jhodgdon |
#17 | 855420-17.patch | 5.61 KB | jhodgdon |
#15 | 855420-15.patch | 5.5 KB | jhodgdon |
#12 | 855420-12.patch | 5.52 KB | jhodgdon |
#11 | 855420-11.patch | 5.23 KB | jhodgdon |
Comments
Comment #1
jhodgdonThe text just after that needs fixing:
Should be using $methodname, and probably SomeObjectTypeName::methodSignature ?
Comment #2
aspilicious CreditAttribution: aspilicious commentedthis is the function
maybe you can make a better sentence ;)
There are also some undocumented function headers, so setting this to needs work.
Comment #3
jhodgdonHow about:
Returns the method signature of a function (XML-RPC method system.methodSignature).
A method signature is an array of the input and output types of a method. For instance, the method signature of this function is array('array', 'string'), because it takes an array and returns a string.
@param string $methodname
Name of method to return a method signature for.
@return
An array of types representing the method signature of the function that $methodname maps to.
Comment #4
aspilicious CreditAttribution: aspilicious commentedFirst sentence exceeds 80 characters
Comment #5
jhodgdonDang.
How about
Returns the method signature of a function.
This is the function mapped to the XML-RPC method system.methodSignature.
A method signature is an array of the input and output types of a method. For instance, the method signature of this function is array('array', 'string'), because it takes an array and returns a string.
Comment #6
aspilicious CreditAttribution: aspilicious commented1) fixed some doc errors
2) following functions still need a header
and
Comment #7
aspilicious CreditAttribution: aspilicious commentedComment #8
jhodgdonHow about this? Fixed a few more errors, and adds function headers for those functions.
Comment #9
aspilicious CreditAttribution: aspilicious commentedNeeds wrapping, besides of that this looks good.
Summary:
- This is a total doc cleanup for xmlrpcs
- Adds missing headers
- Don't affect current rtbc critical patches
46 critical left. Go review some!
Comment #10
jhodgdonYeah. I was using a different computer, just upgraded, and the emacs window was too wide (seems to have forgotten my settings, ugh). So it needs a reroll...
Comment #11
jhodgdonHere goes...
Comment #12
jhodgdonHere's a better version.
Comment #13
sun#12: 855420-12.patch queued for re-testing.
Comment #15
jhodgdonHere's a reroll.
Comment #16
sunThanks!
xmlrpc_server() does not really "perform requests", it rather accepts + processes... how about:
"Invokes XML-RPC methods on this server."
(or similar)
Missing (optional) prefix.
s/an/a/, no?
Typo in "RCP"
Why no @param data types here?
Powered by Dreditor.
Comment #17
jhodgdonNot sure what you meant here:
Actually I just noticed that $message could be either a string or FALSE, so I took out the "string" in this line.
Regarding a vs. an for XMLPRC, I thought it was pronounced "ex em el are pee cee", so when I say it, I would say "an XML-RPC request".
I also fixed the RPC/RCP typo, and added a few more @param types. I think we have to omit the type when it could be more than one type?
Anyway, here's another go at the patch... thanks for your review!
Comment #18
jhodgdonComment #19
jhodgdonComment #20
sunoh - I'm no native English speaker - is usage of "an" instead of "a" coupled to pronunciation? (I've no idea, thought it would be only used in conjunction with a following "e" or "o" - in written text.)
Function arguments that can be omitted are documented with a "(optional)" prefix in the @param description. Since $message defaults to FALSE, it's optional and can be omitted, so I think the description should have an "(optional)" prefix.
Yes, no data types if an argument accepts mixed types. (ok, I think that php.net actually documents "mixed" in such cases, but I've no idea what that is good for)
Comment #21
jhodgdonYes - a/an is based on pronunciation. And "an" goes before any vowel sound, not just e or o.
I think in our doc standards discussion about types on @param/@return, we decided not to do "mixed".
And you are right, our standard for optional args looks like this:
So that could be added to the patch above. I will get to it eventually, unless anyone else beats me to it. I think that's the only thing that needs fixing in it -- to find the optional parameters and put (optional) at the beginning of their descriptions?
Comment #22
jhodgdonHere's another go at it. Added a few "optional" notations, and a bit of documentation about what it meant to omit the arg in one of them.
Comment #25
sunThanks!
Comment #26
Dries CreditAttribution: Dries commentedAll goodness. Committed to CVS HEAD.