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

Stubs with record semantics? #12

Open
danielcompton opened this issue Jul 19, 2017 · 4 comments
Open

Stubs with record semantics? #12

danielcompton opened this issue Jul 19, 2017 · 4 comments

Comments

@danielcompton
Copy link

In my service I create components, and then they have config assoc'd onto them before they are started. The components adhere to the component Lifecycle, and also implement protocols for their behaviour.

Shrubbery is great for implementing the protocols, but when my system tries to assoc config into them, it fails because they are not records. Would it be possible to make an option where stubs behave like records?

@bguthrie
Copy link
Owner

That use case makes a lot of sense to me, but I haven't had a chance to think it through yet. I'm not opposed to the idea in principle—I'll take a look.

@danielcompton
Copy link
Author

danielcompton commented Oct 11, 2017

Here's an extremely minimal reify implementation which can handle associng, but doesn't actually keep the keys. This is useful if you don't actually care about the config being assoc'd on, which happens in some cases, especially no-op components.

(defn new-null-reporter []
  (reify
    ErrorReporter
    (-report-error [_ m]
      nil)

    ;; Maplike impl follows
    IPersistentCollection
    (cons [this obj]
      this)
    (count [this]
      0)
    (empty [this]
      this)
    (equiv [this obj]
      (identical? this obj))
    Associative
    (assoc [this k v]
      this)
    (containsKey [this k]
      false)
    (entryAt [this v]
      nil)
    ILookup
    (valAt [this obj]
      nil)
    (valAt [this obj obj2]
      nil)))

@bguthrie
Copy link
Owner

Oh that's extremely helpful, thank you!

From where you stand, do you think there's an argument to be made for making all stubs maplike, or should the library expose a secondary stub-record function? If there's no harm in it—and particularly if it'd be non-breaking—I'm leaning towards the former.

@danielcompton
Copy link
Author

danielcompton commented Oct 12, 2017

I think it would be a pretty good default behaviour to have too. Part of me has a niggling fear that this could lead to latent bugs, where the stub accepts arguments that the real object wouldn't, if the user is stubbing something that isn't a record.

However I think using records is the more common scenario, and also a good design pattern. It could be good to have the default make a record-like, and then give people the option of creating the stub without record semantics if they really want it.

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

No branches or pull requests

2 participants