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.

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.

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.