I use parameters a lot when designing a library which provides customizable behaviors.
Instead of having an (init) procedure in which users can setup stuff for the library, I provide parameters, which are way more flexible. For example, I'm designing an emulator in which you can have memory addresses mapped to different devices. I allow users to provide an (address-decoder) as a parameter so that they don't have to think about where it is used (pretty much everywhere inside the emulator) but can still provide a custom behavior. I find parameters really useful when you want to provide a way for your users to change parts of the inner code of a library without having to actually change the code. Of course, this usage is mostly interesting in impure code. This way also promotes developing small and iterative libraries. Because you can leave responsibility you don't have the time to tackle yet to your users, and fill the gap later on in the development process. One can say "ok, I need a way to allow users to provide address mapping for the emulator, I need to design a big and complex interface to do so", but instead, you just go like "I'll do that later and let the user provide its own code for now". Just my two cents about how I use parameters :) On Friday, August 3, 2018 at 3:52:56 AM UTC+2, gneuner2 wrote: > > > On 8/2/2018 1:24 PM, 'John Clements' via Racket Users wrote: > > I hate to turn a little question into a big one, but… are parameters the > right choice, here? It seems to me that optional parameters would be more > suitable. > > > > Unfortunately, I’ve been on the other side of this fence, too: > parameters are vastly more convenient for implementors than adding optional > parameters to every one of the internal calls. This certainly came up for > me in the construction of a CSV writing library. > > > > I can imagine a bunch of programming patterns that might assist this; > the most obvious one would be an object-like metaphor where parameter > values are represented as an object to which calls are made. Do others have > ideas on a “best practice” for this situation and others like it? > > > > John > > In the case in question, I probably would go the object route as well. > > > Personally, I don't find a lot of use for parameters: my biggest need > for them is in threaded web server code where there may be multiple > instances of a given handler and they need unique identifiers for client > messages, log entries, etc. Generic logging code doesn't know what > thread it's running under, and Racket threads don't have a printable > identifier themselves ... so I parameterize each handler thread with a > useful [to me] identifier. > > But parameters aren't useful for sideways communication between > threads. Almost all my use of continuations is for abort / escape > purposes, and I don't find a lot of need there for the "special var" > stack behavior of parameters. For most code where I might possibly use > parameters, I find they just don't add anything over using "global" > variables. > [I put "global" in quotes to mean only "accessible to all the code that > needs and/or shares the variable" - not necessarily that it is defined > at the top level or exported from its module. Even within modules, not > infrequently I use the idiom of defining multiple functions within a let > that defines their shared state. Generally I prefer to limit an > object's visibility to only that code that needs to see it.] > > But I imagine there are other people who find parameters invaluable in > their work. Their utility for file I/O using standard ports is obvious > ... I just don't tend to write a lot of that kind of code. > > YMMV. > George > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
