On Mon, Jul 27, 2015 at 9:56 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >>> >>> And let me remind you that despite that NB implements FFI to speak with >>> C, it is not obliged to implement features of C language itself. It lets >>> you speak with C programs, but not lets you write programs like in C (see >>> the difference? :) >> >> I wasn't implying that implicit type conversion was a good thing that >> needed implementing -- but just a bump if it hadn't needed attention >> to it before when C did it automagically. >> cheers -ben > > > Of course, Ben, i understand that you may miss some of the feature(s), you > get used to when doing things in C.
Sorry I wasn't clear so just to emphasise, I agree NB should not implement such a feature. I was trying to say just that it should be explicit** that implicit type conversions are not supported. A lot of programmers at various levels of experience not very aware of implicit type conversions will probably be bitten by the same error. So to avoid the bites, I guess we need to teach this bit of C when teaching NB. ** perhaps with an example demonstrating it, but I don't know what that might be. cheers -ben > But then consider what is involved to implement such feature because it > means determining argument types at run time (at compile time it is > impossible as well as 'compile once when it is invoked for the first time' > that NB does ) > That means that no matter how well you try, the implementation will suck.. > because it will be very slow comparing to one that uses fixed-type > fixed-argument number. > > My philosophy , in general, for programming is avoid bloat and inefficiency > at all costs. When some feature requires bloat and going to be very > inefficient, i simply saying 'No'. > Especially at infrastructural level, which NB belongs to. > Because one thing that you (of me) as implementer knows what is fast & cool > and what is slow & inefficient, but then users come and start using things > in a way you would never think your stuff will be ever used.. and start > spreading inefficiency in their project(s). And more that that, once they > get used to it, then you would be never able to remove it because it is > there and everyone using it and some even loving it :) > > > -- > Best regards, > Igor Stasenko.
