Visual D intellisense now showing members
DigitalDesigns
DigitalDesigns at gmail.com
Wed Jun 6 22:45:20 UTC 2018
I have the json being generated and in it, it shows any members
for intellisense(and even the debugger) except init, sizeof,
mangleof, stringof.
I did a simple test program and it does work but not in my
program. (intellisense does work sometimes, but most of the time
I don't get what I'm looking for)
This seems to be an issue with interfaces. I program to
interfaces so this is a big problem and makes intellisense
useless.
The problem seems to be the file key and that I auto generate
members!
import std.stdio, mTraits;
interface I
{
@property int Q();
mixin(InterfaceFromClass!(A));
}
abstract class A : I
{
@("InterfaceMembers")
{
protected double x = 1;
@property double X() { return x; }
@property A X(double v) { x = v; return cast(A)this;}
}
@property int Q() { return 3;}
}
class C : A
{
int y;
int foo() { return y; }
}
void main()
{
I i = new C();
A a = new C();
// No auto generated members found for i, only i.Q shows in
intellisense. a shows everything.
}
The json is:
[
{
"kind" : "module",
"file" : "main.d",
"members" : [
{
"name" : "std.stdio",
"kind" : "import",
"line" : 1,
"char" : 8,
"protection" : "private"
},
{
"name" : "mTraits",
"kind" : "import",
"line" : 1,
"char" : 19,
"protection" : "private"
},
{
"name" : "I",
"kind" : "interface",
"line" : 5,
"char" : 1,
"members" : [
{
"name" : "Q",
"kind" : "function",
"line" : 7,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
},
{
"name" : "X",
"kind" : "function",
"file" : "main.d-mixin-8",
"line" : 8,
"char" : 20,
"storageClass" : [
"abstract"
],
"deco" : "FNdZd"
},
{
"name" : "X",
"kind" : "function",
"line" : 9,
"char" : 15,
"storageClass" : [
"abstract"
],
"deco" : "FNddZC4main1A",
"parameters" : [
{
"name" : "v",
"deco" : "d"
}
]
},
{
"name" : "Q",
"kind" : "function",
"line" : 10,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
}
]
},
{
"name" : "A",
"kind" : "class",
"file" : "main.d",
"line" : 12,
"char" : 10,
"interfaces" : [
"main.I"
],
"members" : [
{
"name" : "x",
"kind" : "variable",
"protection" : "protected",
"line" : 18,
"char" : 20,
"deco" : "d",
"init" : "1.00000",
"offset" : 16
},
{
"name" : "X",
"kind" : "function",
"line" : 19,
"char" : 20,
"deco" : "FNdZd",
"endline" : 19,
"endchar" : 36,
"overrides" : [
"main.I.X"
]
},
{
"name" : "X",
"kind" : "function",
"line" : 20,
"char" : 15,
"deco" : "FNddZC4main1A",
"parameters" : [
{
"name" : "v",
"deco" : "d"
}
],
"endline" : 20,
"endchar" : 55,
"overrides" : [
"main.I.X"
]
},
{
"name" : "Q",
"kind" : "function",
"line" : 24,
"char" : 16,
"deco" : "FNdZi",
"endline" : 24,
"endchar" : 31,
"overrides" : [
"main.I.Q"
]
}
]
},
{
"name" : "C",
"kind" : "class",
"line" : 30,
"char" : 1,
"base" : "main.A",
"members" : [
{
"name" : "y",
"kind" : "variable",
"line" : 32,
"char" : 6,
"deco" : "i",
"offset" : 24
},
{
"name" : "foo",
"kind" : "function",
"line" : 33,
"char" : 6,
"deco" : "FZi",
"endline" : 33,
"endchar" : 24
}
]
},
{
"name" : "main",
"kind" : "function",
"line" : 40,
"char" : 6,
"deco" : "FZv",
"endline" : 50,
"endchar" : 1
}
]
}
]
The difference between Q and X
"name" : "Q",
"kind" : "function",
"line" : 7,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
},
{
"name" : "X",
"kind" : "function",
"file" : "main.d-mixin-8",
"line" : 8,
"char" : 20,
"storageClass" : [
"abstract"
],
"deco" : "FNdZd"
},
and the only difference is the file key and line info. I've
noticed this in my main program too that the file key shows up a
lot while it doesn't in a simple test program.
I'm wondering if that is causing some sort of match error?
There should be no reason why Visual D can get Q but not X.
Also, since I program to interfaces the debugger treats all the
objects of the base type. Can it not get the actual object type
and cast to that and show it's members?
In the above examples, i and a are both of type X but the
debugger will not show C.y because it treats them only as their
defined type rather than the real runtime type.
Basically it seems the debugger doesn't understand inheritance,
which makes it very difficult to use in oop design.
i 0x00B31008 main.I
a 0x00B31020 main.A
[main.C] 0x00B31020 main.C
- main.A 0x00B31020 main.A
object.Object D0006: Error: Type resolve failed
main.I 0x00B31028 main.I
x 1 double
y 0 int
object.Object D0006: Error: Type resolve failed
main.I 0x00B31028 main.I
x 1 double
That is the locals all expanded. note that all main.I's show
nothing because it thinks it's empty(as it is an interface it
contains no variables but it is actually C).
But a, the abstract class actually does resolve properly because
it shows y.
I also get a lot of the object.Object's that never show anything.
I'd rather not even see those errors if they exist. They just
clutter up the window.
It also looks like the way Visual D shows an abstract class is to
show it as the abstract version then it's derived information as
a sub type. I sort of rather have it treat the object as the type
that it is and just have a flat list rather than duplicate a lot
of info. Maybe leave this method as an option but otherwise
"flatten" the hierarchy and remove redundant information. What
the above should really look like:
i 0x00B31008 main.I[main.A[main.C]]
x 1 double
y 0 int
a 0x00B31020 main.A[main.C]
x 1 double
y 0 int
Why? In both cases we just have a C. No reason to make it more
complex than that. Using main.I[main.A[main.C]] or maybe write it
as main.C : main.A : main.I or whatever. In fact, I don't care
about the type all that much as I usually know what the actual
type is. Although, I'd like some info to express the runtime type
just so I can check in some cases(hence the bracket notation).
It would be nice to figure out what is wrong here because it
makes it very difficult for me to debug and write my complex
programs since I use interfaces all over the place. Once they get
to a certain complexity it just starts becoming a nightmare to
make progress. Having to remember ever function with it's correct
syntax and spelling eventually becomes too much.
Unfortunately there is no middle ground. One can't program to
classes or abstract classes because D does not support multiple
inheritance.
If this can work for abstract classes I see no reason why it
can't work for interfaces.
Thanks for any help!
More information about the Digitalmars-d-ide
mailing list