* Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 03:35]: > I think, that it sometimes could be useful as secondary > protection: a feature (perhaps another "pragma"?), which will > cause stripping the spaces from beginning and end of every > inserted string.
http://sqlite.org/lang_createtrigger.html * Zbigniew Baniewski <[EMAIL PROTECTED]> [2008-01-07 17:55]: > Yes: and from the perspective of the makers, perhaps this > doesn't have to look that bad: it's just using some C-function > to strip every string-value directly before insertion... I > don't expect, that this can cause a mess. No, it doesn’t. And the next tiny feature like yours will not cause a mess either. And the next one after that won’t cause a mess either. Now keep addding tiny cannot-cause-a-mess features for two years and the result *will* be a massive mess. http://blog.plover.com/prog/featurism.html Special-purpose features that do not help with anything else have no place in a library that is going to be used by hundreds of thousands of people. Some more on that by Mark Jason Dominus: It’s all right to be so short-sighted when you’re designing software for yourself, but when you design a language that will be used by thousands or millions of people, you have to have more economy. Every feature has a cost in implementation and maintenance and documentation and education, so the language designer has to make every feature count. If a feature isn’t widely useful to many people for many different kinds of tasks, it has negative value. In the limit, to accomplish all the things that people want from a language, unless most of your features are powerful and flexible, you have to include so very many of them that the language becomes an impossible morass. (Of course, there is another theory which states that this has already happened.) This came as no surprise to me. I maintain the Memoize module, which is fairly popular. People would frequently send me mail asking me to add a certain feature, such as timed expiration of cached data. I would reply that I didn’t want to do that, because it would slow down the module for everyone, and it would not help the next time I got a similar but slightly different request, such as a request for data that expires when it has been used a fixed number of times. The response was invariably along the lines of “But what would anyone want to do that for?” And then the following week I would get mail from someone else asking for expiration of data after it had been used a fixed number of times, and I would say that I didn’t want to put this in because it wouldn’t help people with the problem of timed expiration AND THE RESPONSE WOULD BE EXACTLY THE SAME. A module author must be good at foreseeing this sort of thing, and good at finding the best compromise solution for everyone’s problems, not just the butt-pimple of the week. A language designer must be even better at doing this, because many, many people will be stuck with the language for years. SQLite’s design doesn’t quite constitute a full-blown language, but it’s more demanding than a plain library. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
