Mirror of forum.nim-lang.org

10622 :: What are drawbacks of using forward declarations with "include" as a "module interface"-mechanism?

• Isofruit (orginal) [2023-11-09T21:58:34+01:00] view original

  This occurred to me a couple weeks back but I honestly couldn't see much of a drawback, so I got curious about how it is seen by others.

  Theoretically speaking, you can use forward declarations to force a module to implement a proc.

  So this is possible:

  #moduleInterface.nim
  proc x1(y: string)
  proc x2(y: int)
  
  #main.nim
  include moduleInterface
  
  proc x1(y: string) = echo "implemented x1"
  proc x2(y: int) = echo "Implemented x2"
  Run

  This guarantees me that main.nim implements x1 and x2 with exactly the defined signatures at compile-time. I was already made aware that apparently nobody uses forward-declarations for sort of "interfaces" like that, I just wondered if there are drawbacks to this approach or just better ways to do it.

  What I like about using forward-declarations this way is basically:

  • It's standard nim, no extra package necessary
  • It's compile-time validated
  • It's (in my eyes) exactly how I imagine a module interface: A dedicated file that you can "import" (here include) and it leads to forcing an implementation

  Does maybe the include syntax cause some fundamental problems that I don't yet see?

---

• PMunch (orginal) [2023-11-09T23:23:59+01:00] view original

  I would assume that the problem lies in how this is validated for a type. Say you want to create an interface, it typically needs the concept of a self parameter which is the type that "owns" the implementation. This would traditionally be the class which implements the interface. So how do you express this in your included interface file? One option would be to require the file to define a type and include a using instruction before the include. Otherwise you'd have to hack something together with generics (although I'm not sure this would even work). And after you've actually managed to define something with this interface you can't require it. There'd be no type which encompasses modules that implement this interface. To do that you would need a concept, and at that point all your solution provides is better error messages for missing implementations (which to be honest might be worth it).

---

• Araq (orginal) [2023-11-10T05:27:24+01:00] view original

  The reason why we don't use it for os.nim etc is that it doesn't work well with Nim's effect system. In addition to that, you cannot forward declare iterators, templates and macros.

  But yes, the idea has plenty of merit.

---

• Isofruit (orginal) [2023-11-10T08:10:48+01:00] view original

  Interestingly enough often times I don't actually need a concept in any capacity, it's that the same operation on an identical type is supposed to be performed in N different ways.

  Example: Password hashing. The type you operate on is always type Password = distinct string. However how you hash that (with pbkdf2 and sha256, sha512, or you use argon or whatever) is different. That's what I do in nimword.

  Same thing in my web-application where I generate entire CRUD endpoint groups based on a norm model. Since they all inherit from norm's Model type you only need to define specific procs based on Model.

  Also something I just realized: For me a benefit of that approach would also be that the specs of that interface are explicitly defined and provided in a single, concise overview. And that is something I tend to value a fair bit.

---