[swift-evolution] Custom summary for Mirrors?
Dave Abrahams
dabrahams at apple.com
Tue Jan 5 19:37:01 CST 2016
> On Jan 5, 2016, at 5:28 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hi Joe,
>
> I respect the choice of the team to use Custom[Debug]StringConvertible in lieu of summary. At the same time, in my opinion the output of dump() has become significantly more difficult to read (c.f. unit tests in https://github.com/apple/swift/pull/838/files <https://github.com/apple/swift/pull/838/files>).
Specific examples of readability regressions, please?
> Would you and the team be open to exploring alternative solutions that improve the readability of dump() without increasing API surface area?
Sure.
> For example, perhaps the reflection machinery itself should have special handling for some of the built-in types. If not, I'll consider this discussion thread complete.
>
> Thanks,
> Austin
>
>
>
> On Tue, Jan 5, 2016 at 3:22 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
> Getting custom summaries for the common CG types certainly seems reasonable. We'd have to get approval from the appropriate teams at Apple, but I can't see any objections.
>
> Jordan
>
>
>> On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> I believe 'summary' is obsolete, and you're supposed to use Custom[Debug]StringConvertible to customize your type's reporting now.
>>
>> -Joe
>>
>>> On Dec 29, 2015, at 10:38 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Hi all,
>>>
>>> I'd like to gauge reaction for a proposal I was considering: adding to the standard library's Mirror type a 'summary' property, and the option to initialize a Mirror with a custom summary. If no custom summary is provided, the summary would default to the string produced by calling String(reflecting: subject) on the subject at the time of mirror creation.
>>>
>>> Some context: right now, there are two APIs for mirrors in the standard library: CustomReflectable, which is publicly exposed and relies on the conforming type creating a Mirror object, and _Reflectable, which relies on the conforming type having a companion type conforming to _MirrorType. A short-term goal is to migrate the standard library's types off the _Reflectable API and have them use the CustomReflectable API, and changing dump() accordingly.
>>>
>>> The extant implementation of dump() uses a property on _MirrorType called "summary". (This is where e.g. "4 elements" comes from when you dump() an array.) "summary" is absent from Mirror or any types related to CustomReflectable. I asked Joe Groff about this and the rationale was that it was deemed too similar to debugDescription (or String(reflecting: foo)) to be worth carrying over.
>>>
>>> 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.
>>>
>>> - 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 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
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/93638a75/attachment.html>
More information about the swift-evolution
mailing list