Skip to content
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

Hover Docs Don't Work for Built-in Member Functions #134

Open
michaelalandawson opened this issue Oct 9, 2020 · 2 comments
Open

Hover Docs Don't Work for Built-in Member Functions #134

michaelalandawson opened this issue Oct 9, 2020 · 2 comments

Comments

@michaelalandawson
Copy link
Contributor

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")

@jcberquist
Copy link
Owner

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.

@michaelalandawson
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants