Swift _Class to-many accessors recurse infinitely #227

Closed
fritza opened this Issue Jul 22, 2014 · 6 comments

Projects

None yet

5 participants

@fritza
fritza commented Jul 22, 2014

Consider entity Passer, which is one-to-many with entity Games. mogenerator creates these extensions in _Passer.swift:

extension _Passer {

    func addGames(objects: NSSet) {
        self.gamesSet().unionSet(objects)
    }

    func removeGames(objects: NSSet) {
        self.gamesSet().minusSet(objects)
    }

    func addGamesObject(value: Game!) {
        self.gamesSet().addObject(value)
    }

    func removeGamesObject(value: Game!) {
        self.gamesSet().removeObject(value)
    }
}

When I get to the line

            newGame.passer = passer

… Core data hits the inverse, the @NSManaged games set.

This results (surprisingly rapidly — Swift is beginning to live up to its potential for speed) in a stack 112,165 frames deep, recurring through addGamesObject(Game!).

I infer that NSManagedObject implements the to-many Set proxies in terms of the already-synthesized (just never declared) add{Relationship}Object (etc.) methods. That’s what I see in the disassembly.

I commented the to-many extension out, and the application runs as expected. I imagine this is a Simple Matter Of Programming™ with the Swift template, and I’d offer a pull request, but there are so many damn branches, I don’t know which I should work against.

Anyone else seeing this?

@unregistered

Can confirm, not sure what the side effect of removing the convenience methods will be except for a lack of convenience maybe

@fritza
fritza commented Jul 30, 2014

In my experience: No loss. Swift seems to figure out the implicit methods.

Of course, it's a moving target, and the feature may have disappeared by now.

— F

On Jul 30, 2014, at 3:23 PM, Chris notifications@github.com wrote:

Can confirm, not sure what the side effect of removing the convenience methods will be except for a lack of convenience maybe


Reply to this email directly or view it on GitHub.

@Scenario

My app used these methods so the deletion of the accessors broke me. I had to restore them all from git and move them into my human files to resume work.

I was seeing a crash/hang involved in ordered to-many relationships, but the workaround there was not to set an inverse relationship. That of course caused build warnings but it ran without error.

Are you saying there is a direct way in Swift to use to-many and ordered to-many relationships without these accessors (or their proxy sets which were also removed)?

@Scenario

I just commented out those extensions and got several "unresolved identifier" errors on calls like:

addGames()
removeGames()
addGamesObject()
removeGamesObject()

The errors occur whether the to-many relationship is ordered or not.

So I don't think those accessors are synthesized in Beta 6. In other words, it looks like we need them — unless I'm missing something here. :)

@rokgregoric
Contributor

The accessors are not synthesized .. but in reality you don't need them .. you can access the NSSet or NSOrderedSet and update it.

But actually I agree it's nice to have them around .. so:
rokgregoric@e5c0ffb

Would this solve your issue?

@justin
Collaborator
justin commented Mar 22, 2016

We are declaring pull request and issue 0 now that 1.3 is out. If this is still an issue you'd like to see address with 1.30 and going forward, please open a new issue so we can start a fresh discussion. Thank you!

@justin justin closed this Mar 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment