[swift-users] So how do you implement a NSTextStorage subclass in Swift?

Karl Wagner razielim at gmail.com
Sun Feb 12 17:41:54 CST 2017


  
  
I've seen this before; I considered it something to be resolved in AppKit. Strings in Swift are values, and the framework expects it to be a reference. Since NSTextStorage is itself a reference-type and informs its delegate of changes, those frameworks should probably retain the NSTS itself and pull Strings out as-needed.    
  
  
  

  
Once the new String model is done (long time yet), I would love it if Apple's CoreText team created a truly Swift (i.e. Protocol-based) NSTextStorage API. You wouldn't necessarily have to provide a stdlib String; any UTF16-encoded Unicode/StringProtocol instance could possibly suffice, allowing you to optimise storage through buffer-gaps and whatnot (doable today with NSMutableString subclass, but you can't subclass a struct).
  

  
- Karl
  
  
  

  
  
>   
> On Feb 10, 2017 at 10:51 pm,  <Jacob Bandes-Storch via swift-users (mailto:swift-users at swift.org)>  wrote:
>   
>   
>   
> Got some clarity on this from Apple folks on Twitter:   https://twitter.com/jtbandes/status/830159670559993856   
>
>   
> On Fri, Feb 10, 2017 at 12:54 PM, Michel Fortin  <michel.fortin at michelf.ca (mailto:michel.fortin at michelf.ca)>  wrote:
>   
> >   
> > I did file one (30314719). I might not have explained the problem clearly enough, I suppose, because at the time I was misinterpreting the API contract thinking it was the new AppKit Touch Bar stuff that was violating it instead. That bug now sits closed and I hesitate opening a new bug for the same problem just to ask it to be fixed in another way.   Meanwhile I found an acceptable workaround that I attached to the existing bug report in addition and I posted all this to the list. Hopefully someone at the right place will notice.  
> >
> >   
> > But yeah... maybe I should file another bug, against Foundation's Swift interface this time, since NSTextStorage's string property comes from NSAttributedString. I'll think about it.  
> >   
> >
> >   
> >
> >   
> >   
> > >   
> > > Le 10 févr. 2017 à 11:36, Jacob Bandes-Storch  <jtbandes at gmail.com (mailto:jtbandes at gmail.com)>  a écrit :
> > >   
> > >   
> > >   
> > > This seems like a bug (missing feature?) in how the API is imported for Swift. You might consider filing a Radar.
> > >   
> > >   
> > >   
> > >   
> > > On Thu, Feb 9, 2017 at 3:12 PM Michel Fortin via swift-users  <swift-users at swift.org (mailto:swift-users at swift.org)>  wrote:
> > >   
> > > > The `string` property of `NSTextStorage` is of type `String`, but the contract it must implement is that it should return the backing store of the attributed string (the underlying `NSMutableString` used as the backing store). It seems to me that this makes it impossible to implement correctly a subclass of `NSTextStorage` in Swift, because Swift automatically wraps the `NSString` into a `String` and the underlying mutable storage is not passed around.
> > > >   
> > > >  Here's the documentation for that method:
> > > >   https://developer.apple.com/reference/foundation/nsattributedstring/1412616-string
> > > >   
> > > >  In case the contract isn't clear from the documentation (it wasn't for me), I got a confirmation as a response in radar 30314719:
> > > >   >  It’s returning a copy of the backing store, but the contract is actually returning the backing store string. The copy storage declaration in the property spec is only used for setter implementation.
> > > >   
> > > >  So looks like this is impossible to model correctly in Swift due to the automatic bridging to `String`. Some APIs in AppKit expect the `NSString` they receive to mutate when mutating the text storage (touch bar suggestions in `NSTextView`) and will do bad things this isn't the case.
> > > >   
> > > >  Obviously, I can work around this by writing some Objective-C code, but it'd be better if I could avoid splitting the class implementation between two languages. There's another way using swizzling to map the Objective-C method to a Swift implementation of the same method that has the correct signature, and that's probably what I'll end up doing unless a better solution can be pointed out to me.
> > > >   
> > > >   
> > > >  --
> > > >  Michel Fortin
> > > >   https://michelf.ca (https://michelf.ca/)
> > > >   
> > > >  _______________________________________________
> > > >  swift-users mailing list
> > > >   swift-users at swift.org (mailto:swift-users at swift.org)
> > > >   https://lists.swift.org/mailman/listinfo/swift-users
> > > >               
> >   
> >   
> >   
> >   
> >   
> >       
> >       
> >       
> >  --   
> >  Michel Fortin   
> >   https://michelf.ca
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >               
>    _______________________________________________ swift-users mailing        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170213/ba1fb148/attachment.html>


More information about the swift-users mailing list