Open michaelalandawson opened 4 years ago
The reason that this is currently the case is that with member functions it is not always obvious what documentation to show. Consider myvar.append(othervar)
. the .append()
call could be the struct member function for structAppend()
or the array member function for arrayAppend()
, or myvar
could be a component with a method append()
and not actually a member function at all. I chose to highlight these all as if they were member function calls since I thought for syntax highlighting purposes that would be the most likely case, but for the docs, even if I assumed that such a call is always a member function, I would still not know whether to show the struct or array docs.
A real solution would be some sort of code analysis to try and figure out what the variable refers to, but that can get complicated. Another possibility would be to offer both sets of documentation and let the user pick between them.
Thanks for the reply. I suspected that might be an issue.
What if there was a simple hierarchy to determine which docs to show?
(1) CF built-in functions
(2) User-defined component functions
(3) User-defined functions.
In the case of .dateFormat()
, the hierarchy would start and stop at (1) because it's a built-in CF function. If I created a myCFC.dateFormat() function, then that's bad on me for doing so.
If I have a function .getEventById()
, then, the hierarchy would skip (1) because that is not a built-in CF function. So, it would show the docs for the matching component.
Putting your mouse cursor over the function in the following code sample will display the hover documentation popup.
x = dateFormat(myDateObject, "yyyy-mm-dd")
However, the hover documentation popup does not appear for member functions. In the following example, a hover window may appear with references to 'dateFormat' in the current, or other, files.
x = myDateObject.dateFormat("yyyy-mm-dd")