factor out function wrapper to module function

kiara commented

2025-08-01 18:00:56 +02:00

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

factor out function wrapper to module function 6fa9c40662

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 referenced this pull request from Fediversity/Fediversity

2025-08-01 18:01:09 +02:00

Complete the data model with a runtime environment and end-to-end test #481

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

kiara commented

2025-08-17 14:07:59 +02:00

Author

Contributor

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

kiara added 1 commit 2025-08-17 17:24:51 +02:00

combine UX with parameter type-check - DRYing TODO fb004a4d4c

requested review from fricklerhandwerk

2025-08-17 17:25:15 +02:00

kiara commented

2025-08-17 17:32:40 +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

factor common logic back out efbe7deddd

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

kiara commented

2025-08-17 23:20:36 +02:00

Author

Contributor

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

kiara referenced this pull request

2025-08-18 10:08:27 +02:00

properly use modular function application to ensure parameter type-checks #13

kiara added 1 commit 2025-08-18 10:24:16 +02:00

rename internal implementation to declare, mirroring apply d066b1d55c

kiara commented

2025-08-18 10:54:38 +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

~~kiara referenced this pull request from Fediversity/Fediversity 2025-08-27 12:11:43 +02:00~~

properly use modular function application to ensure parameter type-checks #499

kiara commented

2025-08-27 12:47:58 +02:00

Author

Contributor

superseded by Fediversity/Fediversity#503.

superseded by https://git.fediversity.eu/Fediversity/Fediversity/pulls/503.

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

factor out function wrapper to module function #9

Pull request closed