.| SQL is not an object |
| Diagnosing why so many attempts to objectify SQL have - and must - fail |
| Author |
| Licence |
Date: 3-Jul-2005.
On comp.lang.perl.modules today I saw another solution to the problem of turning SQL into an object, this one in Message-ID: <1120292616.516505.273280@g49g2000cwa.googlegroups.com>.
It's fascinating that so many programmers have tried to come up with a solution to this 'problem'.
There seem to be several explanations for this:
a) They are solving the wrong problem
b) They overlook other people's solutions, if any
c) They solve part of the problem and then give up
d) Etc
(a) is the saddest, because it suggests they don't understand the problem, and hence should not have developed their solution
(b) is sometimes due to the problem of finding other solutions
(c) shows that the solution can soon become worse than the problem. This too is sad
Looking at Sebastian's code
http://unf.be/~sili/projects/sqlbuilder/sql.html
what /I/ see is a vast amount of code instead of 2 or 3 lines of SQL.
So, I ask: Have you really gained anything? My view is: absolutely not :-(.
This begs the question: Why do so many attempts fail?
My answer is: SQL is a string, and no more than that.
It's /not/ complex like a car or something, which would justify regarding it as an object which can be decomposed.
And by that I mean SQL does not have the internal complexity which justifies trying to decompose it into elements whose combined complexity, in turn, justifies wrapping a class around it.
The various clauses involved in building up a string into an SQL statement mislead people into thinking that the complexity of the clauses justify turning the string into an object.
And the fact that in some languages a string can be an object sets a trap for people, who again think SQL can be forced to become an object.
But this time the explanation is that the strings referred to in the previous sentence are complete(d), whereas you are trying to make each /component/ of the string an attribute of the object, and to make each something to be manipulated independently of the final string, in order to build up that final string.
You've added the complexity all right, but gained nothing in return.
Sorry, but I am convinced your solution to this 'problem' has already failed.
However, don't be discouraged. We all try things which don't work out. You should have seen some of the rubbish I wrote when I was learning Perl [1].
It's called experimentation, in exactly the same way Perl V 4 was an experiment which lead to V 5, and as too V 5 is an on-going experiment which will lead one fine - but far distant - day to V 6 being as wide-spread in production as V 5 is today.
[1] The worst, perhaps, was when I didn't know '~' was an alias for 'home directory' in filenames under Unix. But I prefer to draw a veil over the details...
Ron Savage .
Home page: http://savage.net.au/index.html
This version disguises my email address.
Original version.
Australian Copyright © 2002 Ron Savage. All rights reserved.
All Programs of mine are 'OSI Certified Open Source Software';
you can redistribute them and/or modify them under the terms of
The Artistic License, a copy of which is available at:
http://www.opensource.org/licenses/index.html