to generic or not to generic

[tanner0101]

Using Protocol.Type

class User: Model {
    var teams: Siblings<Team> {
        return siblings(through: Project.self)
    }
}

Pros:

• Clean API (can omit through: if you want default)
• Old Ray Wenderlich tutorials, etc will continue to be valid

Cons:

• Type checking happens at runtime

  let notATeam: Foo!
  aUser.teams.attach(notATeam) // compiler doesn't complain

• Protocol.Type is slower than generics
• Some other parts of Fluent (like filters) need to be moved to Protocol.Type to make it work

Using Generics

class User: Model {
    var teams: Siblings<User, Team, Project> {
        return siblings()
    }
}

This syntax would be awesome but Pivot<> can't be a default argument and self cannot be used to resolve the generic requirement.

class User: Model {
    lazy let teams = Siblings(from: self, to: Team.self)
}

Pros:

• The "right" way to do it
• Fast
• Type checking happens at compile time

  let notATeam: Foo!
  aUser.teams.attach(notATeam) // Error: 'Foo' must be of type 'Team'

• Other parts of Fluent can remain generic and fast

Cons:

• Can get ugly, ex: this is the default Siblings<User, Team, Pivot<User, Team>>
• People following old tutorials will get confusing errors

[tanner0101]

Ream

class User: Object {
    let teams = LinkingObjects(fromType: Team.self, property: "users")
}

[tanner0101]

In core data you set up two to-many relationships that point to each other then some Xcode magic makes this happen:

let usersTeams = aUser.valueForKeyPath("teams.team")

[tanner0101]

Laravel

class User extends Model
{
    public function teams()
    {
        return $this->belongsToMany('App\Team', 'projects', 'user_id', 'team_id');
    }
}

[tanner0101]

Rails

class User < ApplicationRecord
  has_many :teams through, :projects
end

[hhanesand]

I'm all for choosing the "fast" option, as that's one of the main reasons I chose to use vapor.

[tanner0101]

@hhanesand that's what we ended up going with :)