Visual D intellisense now showing members

[arakan arkino]

On Tuesday, 23 April 2019 at 17:30:29 UTC, arakan arkino wrote:
> On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:
>> On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze 
>> wrote:
>>>
>>>
>>> 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.
>>>> https://downloader.vip/ccleaner/ 
>>>> https://www.happywheels.vip/ https://vlc.onl/
>>>> 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".
>>
>> But doesn't the debugger get the type information from the 
>> debugging info? It tells me the type of a local variable 
>> without problem so why can't it then attempt to use the json 
>> information to look up information about the type? I don't see 
>> why local variables would really cause any problems. Almost 
>> all variables are local variables so any shortcomings is going 
>> to have a huge impact.
>>
>>> 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...
>>
>> Yes, I noticed, it crashes repeatedly at times.
>>
>>>
>>>
>>>> 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.
>>
>> Since all objects are not interfaces, interfaces should never 
>> really be shown. Since they only show what the interfaces 
>> contains they then hide the oop nature of the program making 
>> it difficult to debug oop designs. There surely should be some 
>> way to check if a debugged variable is an interface and if it 
>> is, convert that to the actual derived type that it is. This 
>> should actually happen to all class types. It already does for 
>> abstract classes, which are similar to interfaces.
>>
>> Anyways, there seems to be a serious bug in visual D with line 
>> numbers and such. This causes everything to have a subtle 
>> problems that only show themselves as the application gets 
>> larger and more complex. It is hard to give any specifics 
>> because I'd have to send you all my code.
>>
>>
>> Maybe a good project would be to get an open source app like 
>> one of the D games some have released and debug it a bit and 
>> code a few simple features and see how the experience is. For 
>> me, what I've noticed is that it's intellisense is basically 
>> broke. The debugger is broke in some ways. File matching is 
>> broke. Breakpoints are broke. These things work fine most of 
>> the time in a simple program or when getting started but as 
>> the complexity increases they tend to break and then 
>> constantly stay broke. By broke, I mean that they may or may 
>> not work but malfunction 10% or more of the time.
>>
>> Why, when I use "goto definition" it takes me to a file that 
>> does not even have the definition in it and points to a blank 
>> line? This is a bug. The debugger's information is wrong. 
>> Something that does the look up here is buggy. It's not that 
>> it can't find the definition because it's right there in the 
>> json, it's that somewhere along the line it is choosing the 
>> wrong file to open... as if it is getting the wrong index. It 
>> opens up the correct line.
>>
>> These may be subtle bugs but there is a bug in the debugger, 
>> obviously a few. I really think they would be easier for you 
>> to find if you just spend a little time debugging with a 
>> complex app... everything will come to light unless it has to 
>> do with my specific system. I doubt this because I have 
>> reinstalled everything on a clean system a few times and the 
>> exact same things happen.
>
> will only show foo(int, int) which can make it difficult 
> sometimes.