# What is direct parameter assignment useful for? **URL:** \ **Category:** Questions & Answers\ **Created:** [June 2, 2022, 1:28am UTC](https://racket.discourse.group/t/what-is-direct-parameter-assignment-useful-for/1047 "2022-06-02T01:28:19Z")\ **Posts on this page:** 1\ **Page:** 2
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [June 8, 2022, 3:42pm UTC](https://racket.discourse.group/t/what-is-direct-parameter-assignment-useful-for/1047/21 "2022-06-08T15:42:08Z")
I think this is an important point: Defining things in a way that supports a program growing. Sometimes in a new program you know that you have some bit of "configuration". The parameter _signature_ is a super flexible way to handle getting and setting it. You could start with `some-config` being from `make-parameter`. That will _tend_ to do the right thing for most sorts of configuration, even if your program later starts to use multiple threads. However maybe you have some configuration that should _not_ be thread-specific. Well you can redefine `some-config` to be a `case-lambda`, where you use or `set!` a variable, maybe guarded by a semaphore. All of the call sites (where you set or get) can remain the same. You could even redefine `some-config` to be a wrapper around the "raw" thread-cell get/set functions. Or read/write an external data store. Or whatever. So you could say that parameters are not a bad default to start with, plus that "interface" is easy to update to be backed by other representations. * * * Having said all that, some people prefer not to have wrapper abstractions like this. As a program grows, sometimes these abstractions help minimize gratuitous changes... but sometimes they hide necessary changes. As with many things, "it depends"? [Previous page](https://racket.discourse.group/t/what-is-direct-parameter-assignment-useful-for/1047.md?page=1)