Hello, Tomas Volf <~@wolfsden.cz> skribis:
> Ludovic Courtès <l...@gnu.org> writes: [...] >> +++ b/gnu/system/mapped-devices.scm >> @@ -83,6 +83,8 @@ (define-record-type* <mapped-device> %mapped-device >> (source mapped-device-source) ;string | list of strings >> (targets mapped-device-targets) ;list of strings >> (type mapped-device-type) ;<mapped-device-kind> >> + (arguments mapped-device-arguments ;list passed to >> open/close/check >> + (default '())) > > I do not think it is a good idea to expect the same identical list for > all of the operations, so we would need arguments-open, arguments-close > and arguments-check fields. Other that that, this would work, sure. Yeah I wondered about that but I thought that in the worst case the operations could just ignore those arguments; from the user’s viewpoint, that would keep the interface simple. > Only thing I wonder about whether we should be apply-ing the list, or > just passing it as a final arguments. That would be a change in the > calling convention, but all procedures could just be adjusted to take > the extra argument. It’s a backward-compatible change in the calling convention (nothing changes for existing open/close/check methods that accept no keyword arguments). > One question would be how to handle if user passes the extra arguments > to a procedure that is not prepared to handle them. In your approach > (apply) it would be a error due to wrong number of arguments, I am not > sure whether that is ideal. Maybe a warning would be better? Not sure. > Opinions? Yes, you’d get a wrong-type-arg error, similar to what you have if you pass #:random-number 42 in the ‘arguments’ field of a package. It’s not ideal in terms of error reporting, but maybe good enough. Another option would be for instance to always pass a key/value pair; open/close/check methods would have to look up in that list for relevant keys and could provide better error reporting, but the downside is extra boilerplate in those methods. Ludo’.
