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