On 12 August 2016 at 12:13, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 10:42, Peter Lind wrote: > > On 12 August 2016 at 11:25, Lester Caine <les...@lsces.co.uk> wrote: > > > > Thanks for the ideas on this feature. > > > > A few thoughts. > > 1. The RFC for this isn't a change - it's an addition. If it gets > accepted > > and implemented, you still would not have to change your code if you > didn't > > want to. > I think that is the whole point ... > > You're making different points, so maybe you should then be clearer.
> > 2. There are differing ways of using the language. Yours is not better - > > merely different. So I would think a relevant question is: can the RFC in > > point support your style of coding along with that of others. A critical > > point is throwing exceptions on invalid data, which might be hard to > handle. > Exceptions get generated hen something unhandled happens. Simple example > 'divide by zero' only happens if the divisor is zero. If the variable > used has a constraint of 'not zero' and has been validated then the > exception will not be raised. My style would validate the divisor and > only call the divide if it was going to work, others would allow the > divide to fail and MAY actually handle the exception ;) > > That doesn't address the point: if the feature should throw exceptions or not, or allow for both styles. > > 4. I think your suggestions might conflate validation and sanitation - > > these are not the same and cannot be handled as one > That people try to inject malicious input via variables is a different > problem. Firebird database has always preferred parameter data so SQL > injections just don't work, but other stuff does need clearing when > input rather than simply relying on escaping unprocessed output. Again > it's programming sytle? > > No, it's not programming style. Conflating validation and sanitation/escaping is wrong, because the contexts are different. > > That said, I generally think that built-in methods that accept Callables > > are a great way to go. It encourages reuse through modular composition - > > and could likely be a neater way around the throw exception/return error > > code issue. It's obviously doable from userland, but could probably be > > improved if implemented in the language. > > It was the fact that Yasuo was adding these rules into his array > validation stuff that just grates so badly with what is actually needed ... > > > Yasuo was presumably scratching an itch that he (and possibly others) feel. As such, it is in fact "what is actually needed". It just doesn't happen to be what *you* actually need, but that doesn't mean it won't fit perfectly for many others. Regards Peter -- CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15
