Question about the advice in "No one should have to know you’ve used binding"

[Drew Verlee]

 Beyond the main point in "In " No one should have to know you’ve used binding" their seems to be a  claim that their is a trade off between adding a positional param which a very common default that is shared between several functions. The example shows how replacing a shared positional param with a shared var can connect the code without making every caller aware of the connection.

This seems like something of a convince to me as one is less flexible then the other. I would like their to be more discussion around when it would make sense to make this trade off. Maybe only at the application level where you could be sure that the lose of flexibility for concision wasn't costly, but not if its a library where you might want to give callers more options?

[Drew Verlee]

I asked some questions related to this topic on the Clojure Slack Begineers channel. Here is a link to my question Slack conversation with luck you can it and the responses there. It goes on tell around 9pm on Sunday. 

Here is a good comment from someone who i believe has read the section in question 

[Zach Tellman]

Hi Drew, sorry for the late reply to this.  The "binding" sub-chapter is meant to be read in conjunction with the "options map" sub-chapter.  The argument is that large numbers of (often optional) positional params makes code difficult to use, so avoid them.  The typical way to avoid this is via option maps, but `binding` can be appropriate where there is just a single value that needs to be propagated deep into the code, as long as the other properties described in the `binding` sub-chapter hold true.

Does this make sense?  I'd like to make this as clear as possible.

Zach

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/eab5eded-baed-4a74-9f05-36e1e326d29a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Drew Verlee]

Hi Zach,

I think i understand the trade off the book presents when handling the deeply nested value. I would like if it explained some situations when its appropriate to when to have this deeply nested value in the first place. The discussion on slack on the topic focused mainly on trying to avoid situations where you had deeply nested chained functions A calls B which calls C.. etc...

The alternative is to try to flatten the call chain out. As an example A returns data that B uses which returns data that C uses.  I think it would help to motivate the discussion in the book with a concrete example and an explanation of when this type of nesting is necessary. That problem might be orthogonal to the one discussed, maybe it could be its own section?  

Thanks for all your hard work on this.

On Tuesday, September 19, 2017 at 12:44:43 PM UTC-4, Zach Tellman wrote:

Hi Drew, sorry for the late reply to this.  The "binding" sub-chapter is meant to be read in conjunction with the "options map" sub-chapter.  The argument is that large numbers of (often optional) positional params makes code difficult to use, so avoid them.  The typical way to avoid this is via option maps, but `binding` can be appropriate where there is just a single value that needs to be propagated deep into the code, as long as the other properties described in the `binding` sub-chapter hold true.

Does this make sense?  I'd like to make this as clear as possible.

Zach

On Sun, Sep 17, 2017 at 6:51 PM Drew Verlee <drew....@gmail.com> wrote:

I asked some questions related to this topic on the Clojure Slack Begineers channel. Here is a link to my question Slack conversation with luck you can it and the responses there. It goes on tell around 9pm on Sunday. 

Here is a good comment from someone who i believe has read the section in question 

On Sunday, September 17, 2017 at 2:12:20 PM UTC-4, Drew Verlee wrote:

 Beyond the main point in "In " No one should have to know you’ve used binding" their seems to be a  claim that their is a trade off between adding a positional param which a very common default that is shared between several functions. The example shows how replacing a shared positional param with a shared var can connect the code without making every caller aware of the connection.

This seems like something of a convince to me as one is less flexible then the other. I would like their to be more discussion around when it would make sense to make this trade off. Maybe only at the application level where you could be sure that the lose of flexibility for concision wasn't costly, but not if its a library where you might want to give callers more options?

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clojure+unsub...@googlegroups.com.