www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Debugger shows base as type

reply Michelle Long <HappyDance321 gmail.com> writes:
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.
Dec 15 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.


shows it in curly braces after the declared type.
Dec 17 2018
parent Michelle Long <HappyDance321 gmail.com> writes:
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. 




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.
Dec 17 2018