Visual D intellisense now showing members

[Rainer Schuetze]

On 07/06/2018 00:45, DigitalDesigns wrote:
> 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!

That's probably the problem.

Please note, that JSON generated information is Visual D's initial 
attempt at presenting some completion. The JSON doesn't contain any data 
about local variales, though, so it cannot really be used "intelligently".

Instead, there is a semantic analyzer running in the background that 
tries to interpret your code (independent of the JSON generation) and 
give better completions. Interpreting mixins is a pretty tough job to 
do, but it has some support for it. You have to enable it in the 
language options, though. Maybe you are lucky...

The only theoretical advantage that remains for the JSON information is 
that you don't need to import a module to get a function listed in the 
completion box. The semantic engine will only present symbols actually 
visible through current imports.

 > [...]


> 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.

The debugger understands class inheritence, but not interfaces. I'll 
have to see whether that's feasible.

> 
> 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.

That's lack of debug information for object.Object. You can add -gf as 
an additional option to instruct the compiler to emit it (or wait for 
the next Visual D release).

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

Interesting idea, a flat view makes sense. The current way mimicks what 
you get in C++.

> 
> 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!
> 
> 
>