Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RefMap or resolve as protocol method #63

Closed
clyfe opened this issue Dec 27, 2019 · 5 comments
Closed

RefMap or resolve as protocol method #63

clyfe opened this issue Dec 27, 2019 · 5 comments

Comments

@clyfe
Copy link

clyfe commented Dec 27, 2019

RefMap would be like RefSet but would resolve to a map {k -> ref} instead a refs set. Knowing the key can be useful (think handler registration).
Alternatively, extend the RefLike protocol with a resolve method and in expand-key postwalk the config via it, this would allow custom RefThings. Sample:

(defprotocol RefLike
  (ref-key [r] "Return the key of the reference.")
  (resolve [r config]))
;; ...
(defn- expand-key [config value]
  (walk/postwalk
   #(cond
      (reflike? %) (resolve % config)
      :else %)
   value))
@clyfe
Copy link
Author

clyfe commented Dec 28, 2019

I just noticed the resolve-key multi-method in 0.8.0-alpha, which can be used to bring the key into the output; nevertheless, the notes above are still desirable to have.

clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 28, 2019
The refmap construct is similar to refset, but returns a map from keys to
resolved refs.
@clyfe
Copy link
Author

clyfe commented Dec 28, 2019

PR #64

@weavejester
Copy link
Owner

Knowing the key can be useful (think handler registration).

Can you explain your use-case further?

@clyfe
Copy link
Author

clyfe commented Dec 28, 2019

In the config map I want to have:

  • a bunch of event handlers
  • that handle events with the same name as the key they are mapped under
  • collect them via refmap and register them in the event reactor

Outcome in the system map:

  • handler under key :k handles events named :k
  • under key :k I have the handler fn and not some complication like {:ev :k :fn h}

Something along these lines:

;; ns registry
(derive ::handler :module/const)

(defn register [[k v]]
  #_(... register v to handle events named k))

(defmethod ig/init-key ::handlers [_ handlers]
  (run! register handlers)
  handlers)

;; ns my.handlers
(defn foo ...)
(defn bar ...)

(derive ::foo ::registry/handler)
(derive ::bar ::registry/handler)

(def config {::foo foo
             ::bar bar
             ::registry/handlers (ig/refmap ::registry/handler)})

clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 29, 2019
The refmap construct is similar to refset, but resolves to a map from
keys to resolved refs, rather than a set of refs; it is useful when the
keys are meaningful to the logic beyond just being a slot in the config
map, and are required in further logic.

Resolves weavejester#63
clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 31, 2019
This allows implementing "RefThing"s beyond just Ref & RefSet that resolve
in a custom way. For example a RefMap would be like RefSet but would
resolve to a map `{k -> ref}` instead a refs set.

Related to weavejester#63
clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 31, 2019
The refmap construct is similar to refset, but resolves to a map from
keys to resolved refs, rather than a set of refs; it is useful when the
keys are meaningful to the logic beyond just being a slot in the config
map, and are required in further logic.

Resolves weavejester#63
clyfe pushed a commit to clyfe/integrant that referenced this issue Jan 8, 2020
This allows implementing "RefThing"s beyond just Ref & RefSet that resolve
in a custom way. For example a RefMap would be like RefSet but would
resolve to a map `{k -> ref}` instead a refs set.

Related to weavejester#63
clyfe pushed a commit to clyfe/integrant that referenced this issue Jan 9, 2020
This allows implementing "RefThing"s beyond just Ref & RefSet that resolve
in a custom way. For example a RefMap would be like RefSet but would
resolve to a map `{k -> ref}` instead a refs set.

Related to weavejester#63
clyfe pushed a commit to clyfe/integrant that referenced this issue Jan 9, 2020
This allows custom references to be added that resolve in different
ways. For example, a RefMap type might act the same as a RefSet, but
include the keys for each referenced value.

See issue weavejester#63.
clyfe pushed a commit to clyfe/integrant that referenced this issue Jan 10, 2020
The refmap construct is similar to refset, but resolves to a map from
keys to resolved refs, rather than a set of refs; it is useful when the
keys are meaningful to the logic beyond just being a slot in the config
map, and are required in further logic.

Resolves weavejester#63
@clyfe
Copy link
Author

clyfe commented Jan 11, 2020

RefLike protocol was extended. RefMap construct was not accepted into the core.
Standalone RefMap implementation based on the extended RefLike protocol is here: https://github.com/tape-framework/refmap

@clyfe clyfe closed this as completed Jan 11, 2020
clyfe pushed a commit to clyfe/integrant that referenced this issue Nov 30, 2020
These methods allow a RefLike implementation to determine which
dependencies are optional for a reflike, and which dependencies are
mandatory.
Also renames `include-refsets?` to `optional-deps?`.

Resolves: weavejester#77
See also: weavejester#63, weavejester#68
clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 5, 2020
These methods allow a RefLike implementation to determine which
dependencies are optional for a reflike, and which dependencies are
mandatory.
Also renames `include-refsets?` to `optional-deps?`.

Resolves: weavejester#77
See also: weavejester#63, weavejester#68
clyfe pushed a commit to clyfe/integrant that referenced this issue Dec 5, 2020
These methods allow a RefLike implementation to determine which
dependencies are optional for a reflike, and which dependencies are
mandatory.

Resolves: weavejester#77
See also: weavejester#63, weavejester#68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants