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. 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.
Otherwise, the alternative would be to write all interfacing code in C (Slang would not be an option with 5 parameters) and create new primitives/plugins. The exact opposite of FFI.
Or even worse in terms of costs/benefits, rewrite LAPACK+BLAS.
Because first, you introduce it because you need it to deal with external world (only for 1% of cases, and in 0% of cases for good written smalltalk code). But that's only at beginning. Once people discover that they have no limits, i bet they will start abusing it in most horrible manner you ever seen.
With such arguments you will soon want to protect us against some evil super powers like become: thisContext etc... ;) Don't castrate us and let us manage the risk of having 15+ parameters.
Yes, you are right. Another philosophy of mine is that system should not put artificial barriers for developer. He should be able to choose what is good for him, not system nor its authors. So i have two contradicting philosophies :) I think we can easily have more than 15 args with Opal compiler. And i will gladly add support for that in NativeBoost. Fixing existing compiler is a waste of time as to me.
Nicolas
-- Best regards, Igor Stasenko.