18 vscode hoverprovider ls #212
Conversation
|
|
||
| object HoverItem { | ||
| implicit val rw: RW[HoverItem] = macroRW | ||
| implicit val rwLocation: RW[Location] = macroRW |
There was a problem hiding this comment.
I'm not exactly sure what these variables do but the other objects have them so I just copied them.
There was a problem hiding this comment.
These will be used by apex-ls own RPC implementation to do the json serialization. We are not using that right now, so the rpc endpoint is not fully defined yet. Given a certain type, it will use the implicit val for that type (which is why we also need another val for the Location type) to perform the serialise.
| return toString + " implements " + interfaces.map(i => i.name).mkString(", ") | ||
| } else if ( | ||
| // Seems like all classes extend a default 'Object$' class | ||
| superClassDeclaration.isDefined && superClassDeclaration.get.name.value != "Object$" |
There was a problem hiding this comment.
I feel like there is a different way to do this that isn't a string check - something like superClass.contains(TypeNames.InternalObject) might do it ? @kjonescertinia help
There was a problem hiding this comment.
Yeah, that should do it, superClass just gives you the TypeName which is cheap, superClassDeclaration resolves the type to give you the declaration object which can be a bit more expensive.
The other bit to handle here is classes which have both a superclass and implement some interfaces. I would probably structure that just as string concat of parts where the parts may have content like "extends A" or maybe empty.
One extra bit is that if you can make use of the toString on TypeName. It masks some of the internal names to make things a bit more readable e.g. for InternalObject it will give you "Object" not "Internal.Object$".
There was a problem hiding this comment.
I have made these changes. Also added a test case for when a class extends and implements.
No description provided.