Debugger shows base as type

[Michelle Long]

On Monday, 17 December 2018 at 08:36:22 UTC, Rainer Schuetze 
wrote:
>
>
> On 16/12/2018 05:14, Michelle Long wrote:
>> The debugger shows a type as it's base type, at least with 
>> arrays:
>> 
>> class A; class B : A;
>> 
>> A[] As;
>> 
>> As ~= B;
>> 
>> Then A[0] is shown as an A.
>> 
>> In fact, it shows A then B inside A, something like
>> 
>> A
>>    B
>>    ...
>> ...
>> 
>> 
>> I think it is more natural to have the most derived shown 
>> first AND if the parent has just one or two fields or three 
>> fields(possibly depending inversely on how many the child has, 
>> up to a max of 10, say) they are consumed by the child.
>> 
>> class A
>> {
>> int x;
>> }
>> 
>> class B : A
>> {
>> int y;
>> int z;
>> }
>> 
>> Would look like
>> 
>> B
>>   x
>>   y
>>   z
>> 
>> while currently it is like
>> 
>> A
>>    B
>>       y
>>       z
>>    x
>> 
>> 
>> 
>> If A had more then it would fall in to a sub tree.
>> 
>> It should always try to use the most derived type for the type 
>> since as programmers that is how we think about them.
>> 
>> This requires us digging down a hierarchy to find the types 
>> values that we generally want to know most about.
>
> There's already the option to show base class members as part 
> of a flat list for all members. I guess this should just 
> include the members of the dynamic type aswell. Limiting it to 
> some number of fields seems too arbitrary.
>
> There'd be no display of that derived type anywhere, though. 
> IIRC C# shows it in curly braces after the declared type.


The problem though is that the hierarchy is ordered from base to 
most derived when it should be reversed.

The reason to show a flat list when the number is small is 
because a flat list is always best since the information is 
presented immediately... but if the list is too large then it 
makes it hard find specific variables. Hence, a middle ground.

If you think a fixed number would be too arbitrary then having it 
based on the available real estate would be the best option, but 
I imagine it would be too difficult.

By having an option for the the threshold to flatten would be 
ideal. 0 could mean never flatten, and some large number, say 
-1(uint.max), could mean to always flatten. Some intermediate 
value such as 4 would mean to flatten if the number of variables 
is <= 4.