<adrien>
ygrek: oh, thanks a lot for the poor man's allocation profiler :-)
<hcarty>
Informal API opinion poll: Given a function with lots of optional configuration options, is it better to have a large number of optional parameters or one (or a few) lists of configuration options?
<hcarty>
For example: foo ?color ?length ?width vs foo [`color `red; `length 1; `width 2]
<adrien>
hcarty: do you want to be able to copy the parameters? like storing them on disk and loading them, or using it in several places?
<Anarchos>
hcarty i had this problem and i prefer passing lots of optional options with named parameters
<Anarchos>
hcarty cause grouping them in a list is not logical most of the time
<hcarty>
adrien: Probably not - they are more likely to be specified directly in the code
<adrien>
hcarty: I prefer optional arguments then
<hcarty>
Anarchos: That's a good point. Lots of optional parameters also make the available categories of options a bit more discoverable
<hcarty>
Thank you both!
<hcarty>
This is for the OCaml more OCaml-y, higher level bindings for PLplot's legend and colorbar functions
<adrien>
I might have been influenced by lablgtk too ;-)
<hcarty>
Each has 20+ arguments in the C API, so I'm trying to consolidate and provide sane defaults where possible.
<hcarty>
adrien: Now... is that a good or a bad thing? :-)
<adrien>
hcarty: as long as your arguments fit on two lines or less usually... :P
<adrien>
hcarty: otoh, if you have sane defaults unlike gtk, it's going to be easier and shorter
<hcarty>
My hope is that most cases will require 1 - 3 arguments, with more available when further customization is wanted
dnolen has joined #ocaml
ftrvxmtrx has quit [Read error: Connection reset by peer]
ftrvxmtrx has joined #ocaml
The_third_man has quit [Ping timeout: 264 seconds]
The_third_man has joined #ocaml
The_third_bug has joined #ocaml
The_third_man has quit [Disconnected by services]
The_third_bug has quit [Client Quit]
iratsu has quit [Ping timeout: 255 seconds]
The_third_man has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
iratsu has joined #ocaml
<ygrek>
adrien, you are welcome
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
vext01_ has quit [Quit: brb]
iratsu has quit [Ping timeout: 255 seconds]
iratsu has joined #ocaml
sepp2k has joined #ocaml
sepp2k has quit [Client Quit]
yezariaely has joined #ocaml
yezariaely has left #ocaml []
avsm has joined #ocaml
dnolen has quit [Quit: dnolen]
dnolen has joined #ocaml
sebz has joined #ocaml
* NaCl
wonders why Str is so... limited
<flux>
nacl, well, I guess maybe implementing Coq doesn't need more than that :)
* NaCl
grumbles
<flux>
but seriously, avoid Str, if you ever think of using the same code in threaded environment.. it will die, even if the interface you use looks like it would be thread safe. it isn't.
<flux>
personally I think Str-module should fail to link with threads.
<NaCl>
personally, I think that Pcre should be in the standard library. xD
<flux>
nacl, yes, batteries + pcre should be enough for all practical uses :)
* NaCl
was fiddling with the Facebook puzzle thing