[swift-evolution] Custom summary for Mirrors?

[Dave Abrahams]

on Mon Jan 18 2016, Austin Zheng <austinzheng-AT-gmail.com> wrote:

> Hi Dave,
>
> Thanks for the insight, I think we're on the same page overall. Responses inline.
>
>> On Jan 18, 2016, at 9:56 AM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> Hi Austin, I think we should discuss it here.
>> 
>> First off, dump() was really just added as a proof-of-concept by Joe
>> Groff when he implemented the original mirror system.  We decided to
>> keep it around because it seemed like it might be useful for somebody,
>> but one possibility to consider is that it should be retired.
>> 
>
> Regarding 'dump()', if it was intended 'just' a proof of concept I
> agree with you - it makes sense to consider retirement. Perhaps
> designing a replacement (if one should exist at all) should be
> considered alongside the larger overhaul of the reflection system
> covered in SR-88. It is used quite extensively in the test suite as a
> way to quickly validate the structure of instances under test, so
> removing it would require refactoring many of the unit tests.

Hm.

>> For the rest, see below
>> 
>> on Mon Jan 18 2016, Austin Zheng via swift-evolution
>> <swift-evolution-m3FHrko0VLzYtjvyW6yDsg-AT-public.gmane.org> wrote:
>> 
>>>>>>> I would like to suggest that there might be a purpose for "summary":
>>>>>>> 
>>>>>>> - Types with children, especially container types like arrays, often
>>>>>>> print out a description of their children as part of their debugDescription
>>>>>>> or description, redundant when using an API like dump() which provides a
>>>>>>> structural representation of the children of the subject. In such cases a
>>>>>>> lighter-weight description (like "3 elements") might be more appropriate to
>>>>>>> represent to the user.
>> 
>> Agreed, if we keep dump, we ought to recover that functionality somehow.
>> However, IMO we might be best off synthesizing that text for mirrors
>> with children by using their DisplayStyle and/or checking their
>> conformances.  It doesn't seem to be worth expanding the protocols for.
>
> Agreed, I think we can easily do it internally for the use cases that
> are most important (collections, certain built-in types), etc. It's
> probably out-of-scope for the PR I have out right now
> (https://bugs.swift.org/browse/SR-88
> <https://bugs.swift.org/browse/SR-88>), but maybe I can sketch an
> implementation and we can discuss further on swift-dev. (Since it's
> all internal changes and no public-facing API changes the entire
> swift-evolution process probably isn't necessary.) LMK if you think
> that's the best way to proceed.

It sounds like a fine plan.  You'd have to land it before SR-88 to
keep the tests working, right?

>>>>>>> - Certain types like CGRect don't conform to CustomStringConvertible,
>>>>>>> CustomDebugStringConvertible, Streamable, etc. Having a custom summary for
>>>>>>> these types customized by the corresponding Mirror would allow for a
>>>>>>> 'pretty' representation during reflection in lieu of the ugly one generated
>>>>>>> by the runtime without making more substantial changes to the API which
>>>>>>> might break third-party code (such as conforming CGRect to any of the
>>>>>>> aforementioned protocols).
>> 
>> I don't think it's worth worrying about breakage from adding a
>> CustomDebugStringConvertible conformance to CGRect.
>
> Okay, that makes sense. Since it's a public-facing API change, though,
> I should bring it up on the evolution list and write a proposal. I can
> do that tonight if that's the most sensible way forward.

Sorry, I don't mean to be dense, but what API change are you talking
about making?

>
> Best,
> Austin
>
>> 
>>>>>>> I know that Mirror (and reflection as a whole) are being considered for
>>>>>>> major design changes, so this would be a minor transient change to make the
>>>>>>> API easier to work with in the meantime.
>>>>>>> 
>>>>>>> Please let me know whether or not you think this proposed change is
>>>>>>> meaningful and worthwhile, or if you have any questions.
>>>>>>> 
>>>>>>> Best,
>>>>>>> Austin
>>>> 
>>>> Hey, Austin,
>>>> 
>>>> Is this still something we need to discuss, or did it get resolved
>>>> somehow?
>>>> 
>>>> Thanks,
>>>> Dave
>> 
>> Thanks,
>> Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution