Prev: interrupt sbcl x86-64
Next: porting a Forth program
From: Thomas A. Russ on 10 Mar 2010 20:54
floaiza <floaiza2(a)gmail.com> writes:

> > > Is security the main reason for such a recommendation? Or is there
> > > something else that supports it?
> >
> > No, the main reason is separation of concerns. What does table
> > formatting have to do with database access?
>
> OK. I get your point. However, in my case I am primarily interested in
> formatting the results of SQL SELECT queries. If I separate the
> formatting form the db access I would then have to write extra code to
> grab the result and pass it to the formatting function. That's an
> extra step which, in my case, I can obviate by coupling the formatting
> and the db access, isn't it?

It's still a bad idea to couple them.

If it is tightly coupled and you decide that you actually want to format
two different SQL SELECT queries, then you have to duplicate your code
because things are too intertwined.

So at the very least, you should consider having a query function and a
format function. And although you need to pass the result from one
function to the other that is likely to be fairly trivial. In the
simplest case it would be as easy as

(format-query-results (perform-sql-query query-string))

Now, in real life the functions will be a bit more complicated because
you may need some information from the query string to help format or
otherwise setup the header information for a tabular presentation. But
even with some additional information needed, it is still a good idea to
separate the parts of the code into modular units.

It just makes dealing with the evolution of the code easier. So unless
this is really one-off utility code that you expect to execute only one
time and then throw away, you should go for the modular design.

Even with so-called "one-off" code, using good design principles will
help you because
1. You rarely get it right the first time, so you will be having at
least some code maintenance to worry about.
2. One-off code has this zombie-like ability to become useful for
other things, and so you end up actually using it more than you
may have initially expected. Sometimes it even then ends up in
production code.
3. You get in the habit of using good design practices.



--
Thomas A. Russ, USC/Information Sciences Institute
From: Vassil Nikolov on 11 Mar 2010 00:59

On Wed, 10 Mar 2010 07:50:15 -0800 (PST), floaiza <floaiza2(a)gmail.com> said:

> Five possible ways have been suggested to address the question of how
> to generate a string that is N times some component string, e.g., "-".

Additionally, in cases like this, sometimes it may be useful to look
at things from a higher viewpoint, and, if working in Lisp, to try
to express the processing in terms of conses and symbols, rather
than strings (when possible, of course, but it often is).

Otherwise, for the sake of completeness, there is also

((lambda (n s)
(reduce #'(lambda (s1 s2) (concatenate 'string s1 s2))
(make-array n :initial-element s)))
3 "-")
=> "---"

which has the advantage of obviously having no bugs [*] and the
disadvantage of needing a unicorn ^W sufficiently smart compiler to
be efficient.

[*] It also seems to be close to passing the Norvig-Pitman test (is
the program a fixed point of "translate from a description in
natural language and back", from their tutorial on good Lisp
programming style, q.v., by all means).

---Vassil.


--
No flies need shaving.
First  |  Prev  | 
Pages: 1 2
Prev: interrupt sbcl x86-64
Next: porting a Forth program