There are a few I’m aware of:

  1. Rust-style use (multiple imports per statement, renaming items using as)
  2. Java-style import (single import per statement, no renaming (afaik))
  3. Zig-style let xlib = @import("xlib") (imports as assignments)
  4. C-style #include (no importing, just pastes the code of the named file)
  • eleijeep@piefed.social
    link
    fedilink
    English
    arrow-up
    13
    ·
    3 days ago

    There is a hidden detail that’s worth mentioning about C and C++ style includes: Because compilation and linking are two separate steps, the definitions (included from header files) and the compiled object code that implements those definitions can be kept strictly separate such that you could have two different implementations of the same definitions that are switched in at linker time, for example as a way to provide mock implementations of a specific compilation unit for a unit test, by modifying which object file is passed to the linker.

    In some languages this is harder to do as it would require some fiddling with the classpath (in Java for example) or designing with dependency injection in mind from the beginning (inversion of control).

    I’m not saying it’s a killer feature, but it’s something worth noting nonetheless.

    • TootSweet@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 days ago

      The Java logging library “SLF4J” works basically this way. It’s a “broker” sort of library. You use the SLF4J API to log and there are different backend implementations that can tie your logging statements to an actual logging backend. So you can do things like switching backends without changing code or using one backend (say, to STDOUT) in local and a different one (Syslog, maybe) in prod.