[swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Saagar Jha]

Saagar Jha

> On Jan 9, 2018, at 22:02, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 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/20180109/59cbb6e4/attachment.html>