Type mismatch when using JavaMailEmil about emil

[gabriellemadden]

@eikek amazing, I was struggling with the generic bit but it's much more clear now after getting access out of emil itself! Everything looks a lot better without depending on an implementation. Thanks so much!

[eikek]

Hi @gabriellemadden ,

yeah, this is a bit tricky, because the type for the connection must match the one inside the concrete instance of Emil. In general your code that works on mails (like searchInbox) doesn't need to know the specific type of connection, which is a JavaMailConnection here. This code works for other connections as well, as long as it is executed using the corresponding instance of Emil. Now, there is no other implementation yet, but should you move searchInbox into another module, it wouldn't need a dependency on emil-javamail (and thus no dependency on javamail).

The recommended way is to create the Emil instance, just as you did, but then use it to obtain the Access instance via emil.access. Try to stay away from classes in the internal package, they shouldn't be needed in almost all cases. If you do this, then the type mismatch happens already in that line :). The trick is to use a type C that is defined on the instance emil:

val access: Access[Task, emil.C] = emil.access

def searchInbox: MailOp[Task, emil.C, SearchResult[Mail[Task]]] =
  for {
    inbox <- access.getInbox
    emails <- access.searchAndLoad(inbox, 1)(
      (Subject contains "MySubject")
    )
  } yield emails

emil(imapConf).run(searchInbox)

But this also ties your searchInbox code to some concrete C - that's totally fine for examples or when you simply don't care about being more generic. However, in general I would rewrite it a little to pass in the Access instance like this:

def searchInbox[C](access: Access[Task, C]): MailOp[Task, C, SearchResult[Mail[Task]]] =
  for {
    inbox <- access.getInbox
    emails <- access.searchAndLoad(inbox, 1)(
      (Subject contains "MySubject")
    )
  } yield emails

emil(imapConf).run(searchInbox(emil.access))

This frees you a bit from worring about this Connection type, be it JavaMailConnection or something else. The argument defines what C to use here and this is "hidden" in the concrete instance of Emil that you use at the end. The searchInbox would then also work with other instances of Emil should they exist some day :-).

The return type is on purpose. It could return the more specific type, too. I did not choose this, so the user needs to code against the abstract type Emil and not accidentally against the JavaMailEmil, which I thought should not be necessary.

Hope this helps and hope I was not too confusing….