Thread overview |
---|
April 16, 2017 Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Debugging tuples is pretty hard to decypher. Instead of using _expand_field, could it be possible to display the names of the fields of they exist? After all, the type is listed with the names so it should be easy to get them from the type string and just replace the displayed _expand_field with them. |
April 16, 2017 Re: Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jethro | On Sunday, 16 April 2017 at 21:00:59 UTC, Jethro wrote: > Debugging tuples is pretty hard to decypher. Instead of using _expand_field, could it be possible to display the names of the fields of they exist? > > After all, the type is listed with the names so it should be easy to get them from the type string and just replace the displayed _expand_field with them. Also, when displaying the value in watches, it would be nice to not show the field name, they take up so much room that one can't really see much of the tuple, specially with nested values. {__expand_field_0="A", __expand_field_1={__expand_field_0="B", __expand_field_1=0}, ...} Instead {"A", {"B", 0}, ...} It's much more concise and is not confusing at all. |
April 16, 2017 Re: Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jethro | On other require: Please don't allow expanding strings that do not really need it. e.g., short strings that fit in the value textbox easily. The extra "expand glyph" can be confusing as it doesn't help distinguish between strings and actual arrays. |
April 17, 2017 Re: Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jethro | Also, use the named tuple elements, if they exist, to replace the _expand_field text. So, instead of _expand_field_0 _expand_field_1 _expand_field_2 _expand_field_3 when expanding a tuple in the watch, one would get something like Name Address Zip Other which is much more informative. |
April 18, 2017 Re: Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jethro | Another idea: With tuples, and possibly other types that use enum, instead of giving the integer value, give the enum string name. This way it is more informative. |
April 18, 2017 Re: Better named tuple support? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jethro |
On 17.04.2017 01:43, Jethro wrote:
> On Sunday, 16 April 2017 at 21:00:59 UTC, Jethro wrote:
>> Debugging tuples is pretty hard to decypher. Instead of using
>> _expand_field, could it be possible to display the names of the fields
>> of they exist?
>>
>> After all, the type is listed with the names so it should be easy to
>> get them from the type string and just replace the displayed
>> _expand_field with them.
>
> Also, when displaying the value in watches, it would be nice to not show
> the field name, they take up so much room that one can't really see much
> of the tuple, specially with nested values.
>
> {__expand_field_0="A", __expand_field_1={__expand_field_0="B",
> __expand_field_1=0}, ...}
>
> Instead
>
> {"A", {"B", 0}, ...}
>
> It's much more concise and is not confusing at all.
>
>
Yeah, having an option to hide the field names makes sense. It can help with any struct, not only tuples.
Extracting the names of the fields from the template type string is a bit more involved and very much specialized to the implementation of Tuple. Maybe a VS visualizer works, but I suspect it needs some visualizer macro system in mago.
|
Copyright © 1999-2021 by the D Language Foundation