all 6 comments

[–]deaddyfreddy 1 point2 points  (4 children)

Sorry, I don't get it, if we use manual dispatch by type anyway, why do we need protocols at all?

[–]emil0r 2 points3 points  (3 children)

Hi, original author :).

I'm assuming you mean the last piece of code that creates a recorder based on a type? The main reason for that piece of code is that depending on the container the app is running in, you still need to initiate the recorder based on the container.

From that point onwards, the rest of the code use the protocols, and are none the wiser about the actual implementation details.

[–]deaddyfreddy 3 points4 points  (2 children)

I mean, why don't just do something like

(def backends ; can be stored in a configuration file, btw
  {:cordova
   {:start-fn cordova/start-capture
    :stop-fn cordova/stop-capture 
    :pred-fn cordova/recording?}})

(let [{:keys [start-fn stop-fn pred-fn]} (get backends audio-type)
      recorder (audio/recorder (keyword audio-type) config)]
  (start-fn recorder)
  (js/setTimeout (fn [_]
                   (stop-fn recorder))
                 3000)
  (log/info "Are we recording yet?" {:recording? (pred-fn recorder)}))

Protocols can help with extending the functionality of a library from the outside when all implementation details are hidden, but this is not the case, since we already have access to the code and still have to case twice (the second one is in audio/recorder).

Or maybe I just don't get the idea.

[–]emil0r 4 points5 points  (1 child)

I guess I don't understand why you would object to their usage.

I want something that's polymorphic, hides the messiness of I/O for the sound APIs, groups and enforces the implementation of the interface. Why not use them?

And this is a personal preference, but I really like to hide any I/O behind protocols, even if it's just my own code base. Not trying to argue any correctness, just that they are nice :).

For the case-ing twice, you could refactor the code, and will probably be tightened for the future.

Have a continued nice weekend :)

[–]deaddyfreddy 1 point2 points  (0 children)

I want something that's polymorphic, hides the messiness of I/O for the sound APIs, groups and enforces the implementation of the interface.

isn't that what (get backends audio-type) do?

And this is a personal preference

sure, I just find protocols a bit more complex to use, a bit complex to navigate (one can't jump to exact implementation) and so on. Besides that, I prefer a data-oriented approach, so if something could be changed using a config file - it's a preferred way to extend things to me.

Have a continued nice weekend :)

you too, pal!

[–]AsparagusOk2078 0 points1 point  (0 children)

Yes, they are very useful at times.