Saagar Jha

> On Jan 11, 2018, at 11:22, Connor Wakamo via swift-evolution 
> <> wrote:
>> On Jan 10, 2018, at 4:21 PM, Chris Lattner < 
>> <>> wrote:
>>> On Jan 10, 2018, at 2:10 PM, Connor Wakamo < 
>>> <>> wrote:
>>>> 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?
>>> Riley and Saagar answered this down-thread, but to confirm — returning nil 
>>> would allow some instances of a type to use the “default” playground 
>>> logging presentation while others use an alternate presentation instead.
>> Right, this gets back to the question: what is the use case for this?  When 
>> would a type want to “sometimes” replace the default representation?
>> It seems to me that a type author either wants to take control of 
>> presentation or not.  While I’m sure we could imagine some use case for the 
>> behavior you’re describing, is it big enough to make it worth complicating 
>> the API?
>>> This isn’t handled by `return self` because, unless I’m mistaken, there’s 
>>> no way to detect that from the caller’s side (e.g. with two `Any` values, I 
>>> can’t do `self === self.playgroundRepresentation`). 
>> Ok
>>>> 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 don’t think we can change this to return `Any` instead of `Any?`. I think 
>>> there are potentially cases where a developer might want to selectively 
>>> opt-in to this behavior.
>> Which cases?  How important are they?
> I can think of a couple of cases where this could be useful.
> The first is an enum. Extending Riley’s example from earlier in the thread:
>       enum MyUnion {
>               case string(String)
>               case image(UIImage)
>               case intPair(Int, Int)
>               case none
>       }
> This enum might want to present the string and image cases as strings and 
> images, but treat the intPair and none cases the “default” way for the enum. 
> This is probably not the most compelling example as there is a workaround — 
> return a second enum or other structured type from playgroundRepresentation — 
> but that feels not great.
> The second case, and the one I’m more worried about, is subclassing. If, for 
> instance, you have the following:
>       class FooView: UIView, CustomPlaygroundRepresentable {
>               var playgroundRepresentation: Any {
>                       return “A string describing this view"
>               }
>       }
>       class BarView: FooView {
>               override var playgroundRepresentation: Any {
>                       // BarView instances wanted to be logged as themselves, 
> but there’s no way to express that
>                       return ???
>               }
>       }
> There’s nothing that BarView can do to ensure it gets logged like a view 
> because FooView declared a conformance to CustomPlaygroundRepresentable.
> I’m not sure how important these cases are. If it were just the first one, 
> I’d probably say we can safely ignore it because there’s a reasonable 
> workaround. But the subclassing case worries me because there’s no escape 
> hatch (aside from a potential implementation-defined failsafe).
>>> I also don’t think that `Optional` would get a conditional conformance to 
>>> this. I’m not proposing that any standard library or corelibs types gain 
>>> conformances to this protocol. Instead, it’s up to a playground logger 
>>> (such as PlaygroundLogger in swift-xcode-playground-support 
>>> <>) to recognize 
>>> these types and handle them accordingly. The playground logger would look 
>>> through the `Optional` so that this would effectively be true, but ideally 
>>> the log data generated by a logger would indicate that it was wrapped by 
>>> `Optional.some`.
>> Why not?  I understand that that is how the old algorithm worked, but it 
>> contained a lot of special case hacks due to the state of Swift 1 :-).  This 
>> is a chance to dissolve those away.
> It’s a feature that Optional (and other standard library/corelibs/OS types) 
> don’t conform to CustomPlaygroundRepresentable. In my mind, it’s the role of 
> the PlaygroundLogger library to understand the types for which it wishes to 
> generate an opaque representation instead of the standard/fallback structured 
> representation. So Optional, String, Int, UIColor, NSView, etc. don’t 
> themselves conform to CustomPlaygroundRepresentable — they’re not customizing 
> their presentation in a playground.
> Semi-related to this proposal, I’m working on a rewrite of the 
> PlaygroundLogger library (currently at 
> <
> <>>)
>  which makes it so that the only special standard library behavior it depends 
> on is Mirror — it no longer relies on the Swift runtime (via 
> PlaygroundQuickLook(reflecting:)) to figure out what to log, instead opting 
> to check protocol conformances itself. So if this proposal is accepted into 
> Swift, concurrent with that we’ll have a new PlaygroundLogger implementation 
> which gets rid of as many hacks as possible.
>> To be clear, I would expect that the conformance for optional would be 
>> defined in the playground module along with this protocol - it wouldn’t be 
>> defined in the standard library itself.
>>> One possibility would be to change the API so that it returns an enum. 
>>> Imagine:
>>>     enum PlaygroundLoggingBehavior {
>>>             /// Asks the playground logger to generate the standard logging 
>>> for `self`.
>>>             case standard
>>>             /// Asks the playground logger to generate logging for the 
>>> given `Any` instead of `self`.
>>>             case custom(Any)
>>>     }
>>>     protocol CustomPlaygroundLoggable {
>>>             /// Returns the `PlaygroundLoggingBehavior` to use for `self`.
>>>             var playgroundLoggingBehavior: PlaygroundLoggingBehavior { get }
>>>     }
>>> (To Saagar’s point in another email — you could even add a `case none` to 
>>> PlaygroundLoggingBehavior to inhibit logging of a particular instance.)
>>> `CustomPlaygroundLoggable` would be a little clunkier to implement than 
>>> `CustomPlaygroundRepresentable` is, as in the common case folks would have 
>>> to write `return .custom(…)`. It’s possible that the clarity and additional 
>>> flexibility this grants outweighs that cost; I’m not sure, and would love 
>>> feedback on that.
>> I just don’t understand the usecase for “conditional customizing” at all.  
>> By way of example, we don’t have the ability to do that with 
>> CustomStringConvertible.   What is different about this case?
> I think the big difference with CustomStringConvertible is that it’s possible 
> for a conformance to reimplement the default behavior on its own. For 
> instance, if I have:
>       enum Foo {
>               case one(Any)
>               case two
>       }
> As noted above, recovering the default behavior with 
> CustomPlaygroundRepresentable is not always possible if the return type is 
> `Any`. That very well might be an acceptable trade-off to keep the API simple.
>>>>> /// 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”.
>>> I’m definitely open to different names for this. 
>>> (`CustomPlaygroundRepresentable` was inspired by the API I’m removing, 
>>> `CustomPlaygroundQuickLookable`, as they both take their sole property and 
>>> make them -able.)
>>> I do like the `playgroundDescription` name for the property, but am a 
>>> little hesitant to use the name `CustomPlaygroundConvertible` because 
>>> conforming types can’t be converted to playgrounds. I can’t come up with an 
>>> appropriate word in `CustomPlaygroundThingConvertible` to use in place of 
>>> `Thing`, though. (If we end up pivoting to the enum I described above then 
>>> something like `CustomPlaygroundLoggable` would be more appropriate.)
>> I would strongly recommend aligning with the state of the art in 
>> CustomStringConvertible (which has been extensively discussed) and ignore 
>> the precedent in the existing playground logging stuff (which hasn’t).
> That’s very reasonable. I’ll update the proposal to use 
> CustomPlaygroundConvertible (unless I or someone else can come up with a 
> really good “Thing” for a name like CustomPlaygroundThingConvertible, as that 
> would even better match CustomStringConvertible/CustomDebugStringConvertible).
> Connor
> _______________________________________________
> swift-evolution mailing list
> <>
> <>
swift-evolution mailing list

Reply via email to