On 22 October 2012 12:00, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 22.10.2012 02:37, Igor Stasenko wrote:
On 22 October 2012 01:59, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2012/10/22 Igor Stasenko <siguctua@gmail.com>:
On 22 October 2012 01:20, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
5 parameters???? Igor, you're a dictator ;) Those theories are nice, but unhelpfull when applied to FFI Pragmatically there's not any chance I rewrite LAPACK+BLAS for the sake of purity.
And your workaround (creating a class) is very poor, because maybe classes themselves should not have more than 5 instance variables ;)
Hehe. This is same thing like increasing number of literals for methods (and max distances between jumps). It just makes sense where you deal with external chaotic world. My ideology is simple: prevent that chaos from entering our little peaceful bay.
That's not exactly the philosophy behind FFI. FFI is here to let the user manage the external chaotic world. OK, external peels of the onion should have 5 parameters or less. Near the sprout, you can't raise such barriers, or there is no onion at all.
Well, that's part of developer's responsibility, how to prevent chaos. Needless to say, nobody wants to deal with so many arguments at once (too much space for mistakes). As for my workaround: this mainly, how you tame the complexity in case it is inevitable? Look how code to call that function will look like:
1. passing as array
args := Array new: 100. args at:1 put: x; at:2 put: y; ... at: 100 put: zork
self callFn: args.
self callFn: {x . y} Looks kinda familiar doesnt it? (hint: swap { for ( and . for , ) I for one welcome our new syntactic overlords!
Yes, it looks familiar, but cannot tell where i seen it. Gah.. how i could forget about it?
2. passing as instance of class, or external structure:
args := MyFunctionArgs new. args firstArgumentName: x; secondArgumentName: y; ... hundrethArgumentName: zork. self callFn: args.
admit that dealing with names instead of numbers leaves much less space for mistakes and serves for better clarity at same time. So, even if it is more cumbersome because requires defining extra class, at the end you win much more.
Anyways, if people think it is worth adding indirect argument loader ( in form of param@<index>, but not param@ivar), we can introduce that.
While I often find this a good idea for maintainability, it sorta flies in the face of another of ST's strengths, iterative/exporatory programming. If you are forced to think up front about which parameter classes you need due to a small limit, rather than introduce them ad-hoc when the code really needs the refactoring to remain legible, it slows you down.
Not thinking of FFI specifically, but I have seen lots of evolved mathematical models where a 5-parameter limit upfront would probably lead to either: a) *Really* bad code, ie. making the calculation object stateful by storing in instvars instead. (and in the process, make it really hard to know which instvars are actually part of object state and not temp vars of some calculation) b) Switching to another programming language out of frustration.
keyword message syntax is bad for many arguments.. for such cases i find a positional argument notation more appeal because it is more compact. In any case, a complex math formulas smell equally bad in any programming language (sometime even if written by hand on paper using math notation(s) ;)
Cheers, Henry
-- Best regards, Igor Stasenko.