Re: MI varobj artificial fields

[Jim Ingham <jingham@apple.com>]

On Apr 16, 2008, at 11:06 AM, Aleksandar Ristovski wrote:
> Vladimir Prus wrote:
>> Right now, when you're in C++ program and ask for children of a  
>> varobj
>> that has structure type, you don't the the fields. Instead, you get
>> "public", "private" and "protected" as children.
>>
> Thank you for addressing this!
>
>> I don't think this makes very much sense. Presenting access  
>> specifies in
> UI
>> as items in the tree seems to just clutter things. Especially as in  
>> C++,
>> classes are either POD, with everything public, or real classes, with
> everything
>> private. Protected data is generally frowned upon. So, most often  
>> we'll
> have
>> a lonely "public" or "private" item having all the real item.
>>
>> Furthermore, even if class has a mixture of public, protected and  
>> private
> data,
>> do we expect the user to remember the visibility of the field he's  
>> after?
>
> I don't see a reason to treat them as "children", but I think the
> accessibility info. could be useful as a child's attribute (as someone
> suggested already). If nothing else, for clarity, one (an ide) might  
> choose
> to see/organize fields by accessibility (for whatever reason).

Yeah, I think this was just added so you get the organization for  
free.  Note that if you go switch to an attribute, the UI is going to  
have to reorder the variables to get all the private ones together,  
etc.  The varobj code now does that for you when it puts them into  
children.  But there's no guarantee they'll come that way from the  
debug info, and in fact they sometimes don't.

Note, BTW, I see lots of developers with classes that have public,  
protected & private data, so I'm not sure that whoever is "frowning"  
on various practices is having much success...

Jim