[swift-evolution] Custom summary for Mirrors?

[Austin Zheng]

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.

> 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.

> 
>>>>>> 
>>>>>> - 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160118/ac205773/attachment.html>