No, you got me all wrong, dude
When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth.I have heard this claim from many other OO proponents. I have asked for code examples, and rarely get them. The few that did produce something proved they were either using a lame language (such as C), were lame procedural programmers, and/or did not know how to use a database right. I won't take your word for it without seeing code where OO wipes procedural's ass because you may fit into one or more of those three categories (without knowing it).
SQL is compact because you need further code to process its results No, I mean for what it does, it is usually compact.
By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once So far attempts to include relational algebra into a language library using imperative API's has stunk. The problem is that relational algebra is not imperative, creating a paradigm mismatch, or at least ugly bloat. Remember this joke code?:
\nNORMAL\n\nprint(a + b)\n\nBLOATED\n\nam = new math.ArithmeticManager()\nopA = new math.Operand((float) a)\nopB = new math.Operand((float) b)\nam.addOperand(opA)\nam.addOperand(opB)\nam.operator = new math.operators.Addition()\nam.executeMathOperation()\nsystem.io.output.print(am.mathOperationResult())\n
Scott suggested Hybernate's query language (HQL) to avoid this kind of API bloat. Hybernate is a bastardization of SQL. One problem with it is that it only works with Java. The second problem is that it is close enough to SQL that it is not worth introducing yet another standard. Rather than make SQL++, we might as well come up with a better relational language with more meta abilities and replace SQL altogether. However, if they make HQL work with any language and it is a reasonably well-supported standard, I probably would not complain much.
As far as security holes, one can create procedural cleaning and/or validation functions. Example:
\nsql .= "foo = 'A' and ID = " . sqlNum(myID);\n\nOr perhaps:\n\nandChar(sql, "foo", "A");\nandNum(sql, "ID", myID);\n
Small and simple. (There are other variations on this theme that get fancier.)
Edited by
tablizer
Nov. 4, 2004, 10:46:13 PM EST
No, you got me all wrong, dude
When requirements change, they apply force on design asymetrically. OO allows the design to slip differentially with a minimum of effort; procedural grinds gears and breaks teeth.I have heard this claim from many other OO proponents. I have asked for code examples, and rarely get them. The few that did produce something proved they were either using a lame language (such as C), were lame procedural programmers, and/or did not know how to use a database right. I won't take your word for it without seeing code where OO wipes procedural's ass because you may fit into one or more of those three categories (without knowing it).
SQL is compact because you need further code to process its results No, I mean for what it does, it is usually compact.
By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once So far attempts to include relational algebra into a language library using imperative API's has stunk. The problem is that relational algebra is not imperative, creating a paradigm mismatch, or at least ugly bloat. Remember this joke code?:
NORMAL
print(a + b)
BLOATED
am = new math.ArithmeticManager()
opA = new math.Operand((float) a)
opB = new math.Operand((float) b)
am.addOperand(opA)
am.addOperand(opB)
am.operator = new math.operators.Addition()
am.executeMathOperation()
system.io.output.print(am.mathOperationResult())
Scott suggested Hybernate's query language (HQL) to avoid this kind of API bloat. Hybernate is a bastardization of SQL. One problem with it is that it only works with Java. The second problem is that it is close enough to SQL that it is not worth introducing yet another standard. Rather than make SQL++, we might as well come up with a better relational language with more meta abilities and replace SQL altogether. However, if they make HQL work with any language and it is a reasonably well-supported standard, I probably would not complain much.
As far as security holes, one can create procedural cleaning and/or validation functions. Example:
sql .= "foo = 'A' and ID = " . sqlNum(myID);
Or perhaps:
andChar(sql, "foo", "A");
andNum(sql, "ID", $myID);
Small and simple. (There are other variations on this theme that get fancier.)
________________
oop.ismad.com
