Skip to content
This repository was archived by the owner on Aug 25, 2025. It is now read-only.
This repository was archived by the owner on Aug 25, 2025. It is now read-only.

wire: do not use global variables for all wire.Value expressions #185

Open

Description

@rogpeppe

One of the specific advantages of the wire approach is that it generates code that's relatively readable compared to reflect-based equivalents. When wire.Value is used on a small by-value type, there's no need for the value to live in a global variable - the expression could instead be used literally inside the generated code, which would make the code easier to follow, and more similar to the code that one might write by hand.

Activity

  1. added this to the Unplanned milestone on Jun 7, 2019
  2. zombiezen commented on Jun 7, 2019

    @zombiezen
    Contributor

    The reason we have the semantics we have now for wire.Value is that we want to be confident that the expression will evaluate to the same value that was expressed at the wire.NewSet's evaluation. This keeps the behavior of wire.Value largely unsurprising, and amenable to usage in a runtime DI version if needed at some point.

    It sounds like the request here is that the generated code in some circumstances (like when using a constant expression, for example) could be more efficient, since the time that the expression is evaluated wouldn't matter. That seems reasonable to me, but I think we can add this feature in a backward-compatible way later.

  3. rogpeppe commented on Jun 8, 2019

    @rogpeppe
    Author

    Yes, but it's not just about efficiency. One of the selling points of wire is that the generated is a readable representation of the dependency setup. This is one thing that makes the code less idiomatic/readable

  4. zombiezen commented on Jun 11, 2019

    @zombiezen
    Contributor

    Agreed. To be clear: I think this is a good idea, but we don't have bandwidth to fix it right now. Happy to review PRs to fix.

  5. j4ng5y commented on Jun 25, 2019

    @j4ng5y

    I'll take a stab at this.

  6. removed their assignment
    on Jul 9, 2019
  7. ProgrammingMuffin commented on Dec 15, 2023

    @ProgrammingMuffin

    @zombiezen A few observations here.

    1. Do we need global variables at all, if we provide that value exactly when and where the programmer wanted to provide it.
    2. Do we need backward compatibility, since the generated code is going to overwrite it anyway and wouldn't affect the code unless the programmer is using those generated global values somewhere else. If yes, do we have any ideas on how to make the backward compatibility work?

    Since this issue is still open, I decided to try it out and it works but it's only a local test change (not confident if that's the solution we are looking for),

    Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions