countForFetchRequest & Swift 2

Discussion in 'iOS Programming' started by Mascots, Oct 25, 2015.

  1. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #1
    The delectation for executeFetchRequest was converted for Swift 2:

    func executeFetchRequest(_request: NSFetchRequest) throws -> [AnyObject]​

    while countForFetchRequest still expects an error pointer passed through it:

    func countForFetchRequest(_request: NSFetchRequest, errorerror: NSErrorPointer) -> Int

    So like, did Apple just forget to convert or do you think there was a reason?
     
  2. iphonedude2008 macrumors 65816

    iphonedude2008

    Joined:
    Nov 7, 2009
    Location:
    Irvine, CA
    #2
    No sure. That seems weird that they would forget to convert it. Maybe someone else knows why apple would want to leave the old error pointer stuff in? Obj c compatibility is the only thing I could possibly think of. After all, most of their code is still in obj c.
     
  3. Mascots thread starter macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #3
    They didn't give a rat's about BC with Swift 2, so it seems way inconsistent.

    I know Core Data is suffering during the Swift migration, but I honestly think they just overlooked it.
     
  4. grandM macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #4
    suffering?
     
  5. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #5
    I see it reads: "throws -> [AnyObject]"
    Does that mean that AnyObject would contain the error? Maybe it's because one executes a command and the other returns an Int. In other words, it has to have a way to get to the error object, either by a return or a pointer.
     
  6. Mascots thread starter macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #6
    There have been many issues introduced with Swift in Core Data.
    From the top of my head
    - Broken Xcode NSManagedObject subclass generation
    - Misdocumented side effects of namespacing, pretty much requiring your model to be a framework if you test or use an extension
    - Awkward and inconsistent syntax, mostly from the way they exploit Obj-c's runtime which worked well at one point.
    - Inconsistent adaption to Swift methods ;)

    Overall, there's just a lot of edge cases that you'll only run into while working with it, often requiring a bit of forethought and research.

    I still like it though.
     
  7. Mascots thread starter macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #7
    No error pointer in Swift 2 - the throws signifies an error may be thrown while [AnyObject] refers to the casted NSManagedObject in an array, only. You simply catch the error and don't have to handle a pointer.

    It's in sharp contrast to Objective-C's way, which still seems to affect countForFR.
     

Share This Page