factor out function wrapper to module function #9

Closed
kiara wants to merge 4 commits from data-model-factor-out-wrapper into deployment-data-model-with-tests
Contributor

lifts the { input output } function wrapper out of the user interface to function.nix, simplifying usage.

pre-#13 comments

note that this does not yet add a value-level 'type check' using this type yet, as such a check does not seem to function yet anyway. as such, the point of having function.nix here is to allow for structured type data for the purpose of documentation generation, as suggested at Fediversity/Fediversity#481 (comment).

if we figure out how to make such a type-check work, something like it could be added in data-model.nix like:

function-type-check = mkOption {
  type = application.config.config-mapping.function-type;
  readOnly = true;
  default = input: {
    inherit input;
    output = application.config.config-mapping.implementation-type
input;
  };
};

... or even to function.nix itself, like:

function-type-check = mkOption {
  type = config.function-type;
  readOnly = true;
  default = input: {
    inherit input;
    output = config.implementation-type input;
  };
};
lifts the `{ input output }` function wrapper out of the user interface to `function.nix`, simplifying usage. <details> <summary> pre-#13 comments </summary> ~~note that this does not yet add a value-level 'type check' using this type yet, as such a check does not seem to function yet anyway. as such, the point of having `function.nix` here is to allow for structured type data for the purpose of documentation generation, as suggested at https://git.fediversity.eu/Fediversity/Fediversity/pulls/481#issuecomment-9288.~~ if we figure out how to make such a type-check work, something like it could be added in `data-model.nix` like: ```nix function-type-check = mkOption { type = application.config.config-mapping.function-type; readOnly = true; default = input: { inherit input; output = application.config.config-mapping.implementation-type input; }; }; ``` ... or even to `function.nix` itself, like: ```nix function-type-check = mkOption { type = config.function-type; readOnly = true; default = input: { inherit input; output = config.implementation-type input; }; }; ``` </details>
kiara added 1 commit 2025-08-01 18:00:58 +02:00
note that this does not yet contain the 'type check', as this does not
function yet.
this could be added in `data-model.nix` like:

```nix
function-type-check = mkOption {
  type = application.config.config-mapping.function-type;
  readOnly = true;
  default = input: {
    inherit input;
    output = application.config.config-mapping.implementation-type
input;
  };
};
```

... or even to `function.nix` itself, like:

```nix
function-type-check = mkOption {
  type = config.function-type;
  readOnly = true;
  default = input: {
    inherit input;
    output = config.implementation-type input;
  };
};
```
kiara changed title from factor out function wrapper to module function to WIP: factor out function wrapper to module function 2025-08-17 14:07:36 +02:00
Author
Contributor

marked as WIP again to rebase on #13 (if at all compatible)

marked as WIP again to rebase on #13 (if at all compatible)
kiara added 1 commit 2025-08-17 17:24:51 +02:00
requested review from fricklerhandwerk 2025-08-17 17:25:15 +02:00
Author
Contributor

@fricklerhandwerk my update for #13 here so far worked by duplicating stuff from function.nix - the next step seems figuring out how to resolve that duplication, which i hope you might have some insights on.

@fricklerhandwerk my update for #13 here so far worked by duplicating stuff from `function.nix` - the next step seems figuring out how to resolve that duplication, which i hope you might have some insights on.
kiara added 1 commit 2025-08-17 23:18:03 +02:00
note that i worked around the question of how to delegate part of the
options to the consumer by creating aliases for different parts of the
function slot filling.
i've been pretty arbitrary about this so far tho, and mostly to preserve
existing interfaces, rather than out of conscious UX design per se.
so the interface can def change still, but at least the _user_'s side is
more DRY now!
kiara changed title from WIP: factor out function wrapper to module function to factor out function wrapper to module function 2025-08-17 23:20:01 +02:00
Author
Contributor

ok i'm sorta happier about this now, reviews welcome

ok i'm sorta happier about this now, reviews welcome
kiara added 1 commit 2025-08-18 10:24:16 +02:00
Author
Contributor

i feel like UX-wise there is room for further encapsulation still - my ideal level of abstraction would be like a types.functionFromTo (mirroring the existing types.functionTo) to be used as mkOption { type = types.functionFromTo input-type output-type; default = implementation; }.

one difference may be we do actual type-checks, while i'm under the impression types.functionTo does not.

moreover tho, given my current level of encapsulation, an outstanding challenge to exposing such a transparent encapsulation would be that, as it stands, such a type would not amount to a no-op for the value: the (typed) function we get out (currently: apply) is not the (untyped) function we put in (currently: declare).

now, while nix (afaik) lacks OOP-style getters/setters, i felt like there is a certain level of precedent here in the sense one already cannot just comment type declarations and expect things not to break, e.g. due to submodules declaring calculated attributes through readOnly default values.

i'll have to admit tho, i'm not actually sure it's possible in current nix to reach such a further level of encapsulation here.

i feel like UX-wise there is room for further encapsulation still - my ideal level of abstraction would be like a `types.functionFromTo` (mirroring the existing `types.functionTo`) to be used as `mkOption { type = types.functionFromTo input-type output-type; default = implementation; }`. one difference may be we do actual type-checks, while i'm under the impression `types.functionTo` does not. moreover tho, given my current level of encapsulation, an outstanding challenge to exposing such a transparent encapsulation would be that, as it stands, such a type would not amount to a no-op for the value: the (typed) function we get out (currently: `apply`) is not the (untyped) function we put in (currently: `declare`). now, while nix (afaik) lacks OOP-style getters/setters, i felt like there is a certain level of precedent here in the sense one already cannot just comment type declarations and expect things not to break, e.g. due to `submodule`s declaring calculated attributes through `readOnly` default values. i'll have to admit tho, i'm not actually sure it's possible in current nix to reach such a further level of encapsulation here.
kiara closed this pull request 2025-08-27 00:45:55 +02:00
Author
Contributor
superseded by https://git.fediversity.eu/Fediversity/Fediversity/pulls/503.

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fricklerhandwerk/Fediversity#9
No description provided.