RD currently treats Debug as a dummy class, and Print and Assert as dummy methods.
You can't declare a type of Debug, and you can't use With Debug, so it's not a class. You can't use Debug without using Print or Assert, and you can't use Print (as you do when using Debug) or Assert without using Debug.
Line continuations make for slight complications.
Debug, Print and Assert should be treated as keywords by RD.
You can't declare a type of Debug, and you can't use With Debug, so it's not a class.
To me it looks very much like Debug could be a PublicNotCreatable class with a PredeclaredId, and IntelliSense reinforces that... OTOH the syntax highlighting agrees with the idea that they might be keywords... but then if this is illegal:
Dim False As String
Or this:
Dim Function As Long
Then this is being legal seems to contradict the idea that Assert might be a keyword:
Dim Assert As Rubberduck.AssertClass
TL;DR: I agree that the dummy class is BS, but treating Debug.Print and Debug.Assert as keywords means we can no longer track their references, which means removing a feature for ...for what?
I can't use any of these statements:
MsgBox ObjPtr(Debug)
MsgBox VarPtr(Debug)
MsgBox Debug Is Nothing
MsgBox Not Debug Is Nothing
Msgbox TypeOf Debug Is Debug
Msgbox TypeName(debug)
With Debug
.Print "FOO"
.Assert True
End With
That's fairly strong evidence that Debug isn't an object.
If Debug were predeclared and notcreatable, Print and Assert would appear as methods in Intellisense, but they appear as keywords, and they don't appear at all in the OB. Furthermore, Intellisense doesn't offer any prompts for the arguments
Quick Info (Ctrl + I) doesn't do anything with Debug, Print or Assert.
Likewise, Listing Properties Methods (Ctrl+J) does list Debug, but it's quite clearly a keyword, like Empty, False, True, Null or Nothing. None of those are in OB.
But I hear your point about removing a feature. Maybe we add a dummy flag to a Declaration, and then suppress the type descriptions in the RD status bar, for Debug, Print and Assert.
@Future, if we're annotating the parse tree and getting rid of declarations it shouldn't matter - Debug will just be, well, Debug. Currently it seems convenient to treat Debug like an object, but all it would really take would be deriving a new Declaration type from ClassModuleDeclaration specifically for Debug. Or add an IsDebug flag on the existing one.
Why not treat Debug as a standard module?
@MDoerner that could work, too. Satisfies the Print and Assert being members of Debug, and the non-object nature of it. :+1:
Most helpful comment
Why not treat
Debugas a standard module?