Saagar Jha
> On Jan 9, 2018, at 22:02, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Good afternoon,
>
> Hi Connor,
>
> Huge +1 for this proposal, I’m thrilled you’re cleaning this up. Couple of
> detail questions:
>
>>
>> <https://github.com/cwakamo/swift-evolution/tree/playground-quicklook-api-revamp#proposed-solution>
>> Detailed design
>>
>> To provide a more flexible API, we propose deprecating and ultimately
>> removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable
>> protocol in favor of a simpler design. Instead, we propose introducing a
>> protocol which just provides the ability to return an Any (or nil) that
>> serves as a stand-in for the instance being logged:
>>
>
> What is the use-case for a type conforming to this protocol but returning
> nil? If there is a use case for that, why not have such an implementation
> return “self” instead?
>
> In short, can we change playgroundRepresentation to return Any instead of
> Any?. Among other things, doing so could ease the case of playground
> formatting Optional itself, which should presumably get a conditional
> conformance to this. :-)
I believe the rationale behind this was to provide a way to “opt-out” of a
customized representation, although now that I think about it, what exactly
does the default mean? In particular, what happens in this case?
// I’m not sure how this will be implemented: possibly UIView won’t conform to
CustomPlaygroundRepresentable and the first class inheriting from it will do
this?
// Either way, it shouldn’t really affect my example since this will just mean
that FooView will implement it instead
class UIView: CustomPlaygroundRepresentable {
var playgroundRepresentation: Any? {
return self // I assume this is done somewhere in the bowels of
PlaygroundSupport or whatever
}
}
class FooView: UIView {
override var playgroundRepresentation: Any? {
return “foo”
}
}
class BarView: FooView {
override var playgroundRepresentation: Any? {
return nil
}
}
In this case, what’s the default? UIView’s implementation, or that of the
immediate parent (FooView’s)?
>
>
>> /// Implementors of `CustomPlaygroundRepresentable` may return a value of
>> one of
>> /// the above types to also receive a specialized log representation.
>> /// Implementors may also return any other type, and playground logging will
>> /// generated structured logging for the returned value.
>> public protocol CustomPlaygroundRepresentable {
> On the naming bikeshed, the closest analog to this feature is
> CustomStringConvertible, which is used when a type wants to customize the
> default conversion to string. As such, have you considered
> CustomPlaygroundConvertible for consistency with it?
>
> The only prior art for the word “Representable” in the standard library is
> RawRepresentable, which is quite a different concept.
>
>> /// Returns the custom playground representation for this instance, or nil
>> if
>> /// the default representation should be used.
>> ///
>> /// If this type has value semantics, the instance returned should be
>> /// unaffected by subsequent mutations if possible.
>> var playgroundRepresentation: Any? { get }
> Again to align with CustomStringConvertible which has a ‘description’ member,
> it might make sense to name this member “playgroundDescription”.
>
> Thank you again for pushing this forward, this will be much cleaner!
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
