On 12 August 2016 at 12:52, Lester Caine <les...@lsces.co.uk> wrote: > On 12/08/16 11:23, Peter Lind wrote: > > 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. > > If you don't set a constraint or other 'intelligent' action then nothing > changes? > > This is missing the point entirely. The RFC was for a new feature, that you don't have to use. Not for changing existing ones.
> >>> 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. > > We already have a 'strict' mode which enables exceptions on some actions > or leaves them as errors. I'm simply happy for both to co exist to keep > others happy. > > Good point. > >>> 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. > > The programming style 'point' is that many sites do simply slap > htmlspecialchars() around all output and not worry that internally > suspect data is floating around. On a couple of projects I've been using > this was the sticking plaster while I prefer to ensure that the > variables being passed were clean in the first place. In some situations > sanitising the input may not be practical because of the workflow used > but THAT is a matter of programming style? > > But other programmers entirely foregoing validation is besides the point. The point was that conflating validation with escaping/sanitizing is wrong - and that still applies, even if your chosen method of validation is "I don't". -- CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15
