IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New How is being locked to a DB more evil than being locked to
a specific language?

If you don't want to be locked to a vendor and want to see the DB code, then go with an open-source DB. If you don't use a DB, then you often end up reinventing what database already do:

# Persistence
# Query languages or query ability
# metadata repository
# State management
# Multi-user contention management and concurrency (locks, transactions, rollbacks, etc.)
# Backup and replication of data
# Access security
# Data computation/processing (such as aggregation and cross-referencing)
# Data rule enforcement or validation
# Data export and import utilities
# Multi-language and multi-application data sharing

If you reinvent all these from scratch, then how is that being less "locked in" than an open-source DB? You are simply locked into your own code instead of somebody else's. Over the long-term you probably move on and the next person who comes along has to deal with and learn your non-standard database or its equiv. Isn't it better to get the above features from a semi-standard tool to avoid such a huge learning curve and reinvention? Remember "reuse"?
________________
oop.ismad.com
Expand Edited by tablizer Nov. 2, 2004, 12:39:02 AM EST
New It's best to fit the tool to the job
Fact is, databases are so generic that they fit no problem space. Enter additional layers, specifically frameworks and ORMs, which allow the app developers to encapsulate the generic DB in a domain-specific "little language", thereby reducing complexity. When you can express the same code in fewer terms, you can express more in the same time/space/effort. When you can express the same code in terms from the vocabulary of the domain (as opposed to the vocabulary of the tool, the DB), you save a mental translation step; this reduces time-to-market, miscommunication among developers, and ultimately design and implementation errors.

This is the same reason LISP doesn't take off in popularity--it's too generic. You need a guru to write a "little language" in LISP that enables your problem space; then you can build the killer app on top of that. Visual Basic swept the small business app world because it was tailored to small business apps. This reduced choice and expressivity, but by the same token increased speed and made small business app "programmers" a commodity.

Databases simply don't provide the tools to produce such a grammar between the application domain and the database domain. And they never will; it's in their best interest *not* to, because to do so would reduce their market. A general-purpose programming language does provide such tools.
New Thanks for that ... +5 insightful
That's the best answer I've read to that issue. It confirms my experience that whatever the problem space is, you always start by writing a "little language". Then you write your app using that. Very well put.
===

Implicitly condoning stupidity since 2001.
New For various definitions of "start" ;)
The incremental guys would say you start both processes almost simultaneously. I tend to 1) model on paper, 2) write a prototype, 3) rewrite the prototype a couple times, incorporating the "big lessons" I learned along the way about the domain, 4) deliver the final. Now if I were to write essentially the same app again, I'd skip step 2 and most of 3, but who wants to write the same apps over and over? ;)
New On writing the "little language thing ..."
I remember I once read a statement for ESR (Eric Something Raymonds)
in which he said, that he believe in the school of "make it a language" ...

by "it" I think he meant any program, I don't remember where exactly I read this statement of his, and search but failed to find the article.
But I remember vaguely that he was speaking about RMS and Emacs ...

Anyway this statement stuck in my head (even though I didn't fully grasp it, and don't up until now!)
And I always looked at emacs, as a program that was writen as a language, probably from it's first days.


The thing is, I think, many people have a different idea in their heads, when that say "language"

Elisp is a language ...

Emacs can be seen in an abstract sense as a language .... seperate from Elisp, a language that speaks, C-c C-x , and M-x append-to-buffer <RETURN>

A Class public methods is a language, the language that this class speaks

Any module that you write or language extension (actually in Tcl a library and a language extension are the same thing, also in Tcl some commands (that have a dozen sub command) will be considered as modules in other languages)

The shell command 'find' is it a command, or a module or a language!

Expect, is it a Tcl module, or a tcl command, or a tcl extension, or a language in its own

Gnome or Kde ... can't we call those a language !

Well I believe if you are talking abstractly, then yea of course, any UI or GUI is a language

Even this forum is a language

So what is a language?

If the solution is to create a language (not a program, not a module, not a command) than I need to know, what is a language, what is it composed from, when do I know I completed my language, what feature do I need filled to have a complete language.

I find this way of thinking interesting, and I would like to investigate the school of "make it a language", if it truely exist a bit more ...

Many ppl repeat those words about writing your own mini language or high level language ... so something good must be in it, specially since, that at an abstract level this thought is supported, that any program can be viewed as a language, any library, can be thought of as a language

What is missing is, how can this way of thinking, help me create a better program (language) or better module (language)
I think we can start by having a better or a more specific definition of a 'language'

Also, I want to mention, that read in a few article about Ruby, that ruby makes it very easy to write your own mini language, what a tease, as if every body is doin it, yet, when I search, I can't find any book or article who tell u how to create ur own language, the school of "make it a language", is far from ...
being an everyday thing! It's really not that popular, or elaborated upon.

New Suggestion
Read [link|http://www.paulgraham.com/onlisp.html|OnLisp] to see "the make it a language" philosophy demonstrated very clearly.

It is not necessarily so much that you create a language from scratch (though you can), often it is that you adapt an existing language to give it the vocabulary that you need for your project.

Or as [link|http://www.pragmaticprogrammer.com/ppbook/index.html|The Pragmatic Programmer] says, you want to Program Close to the Problem Domain. Create interfaces for yourself that hide implementation details so that you can stop thinking about how stuff is implemented and start thinking about the end problems in a natural way.

Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New "Little Language" definition, components
So what is a language?

If the solution is to create a language (not a program, not a module, not a command) than I need to know, what is a language, what is it composed from, when do I know I completed my language, what feature do I need filled to have a complete language.

Many ppl repeat those words about writing your own mini language or high level language ... so something good must be in it, specially since, that at an abstract level this thought is supported, that any program can be viewed as a language, any library, can be thought of as a language


Correct; the difference between a "program" and a "language" is one of perspective. You write a program to walk 100m, turn right, walk 110m, turn right, walk 100m, turn right, walk 110m, and maybe turn right. You write a language to go around the block, instead.

What is missing is, how can this way of thinking, help me create a better program (language) or better module (language)
I think we can start by having a better or a more specific definition of a 'language'


Short answer: [link|http://en.wikipedia.org/wiki/Formal_language|read up on "formal languages"].

A little language possesses a vocabulary of functions, classes, modules, and packages which map to concepts in the problem domain. The elements of the vocabulary interact according to a formal grammar. The concepts are determined by self-declaration of human stakeholders, subject to systematic analysis and organization in order to produce a formal system.

Also, I want to mention, that read in a few article about Ruby, that ruby makes it very easy to write your own mini language, what a tease, as if every body is doin it, yet, when I search, I can't find any book or article who tell u how to create ur own language, the school of "make it a language", is far from ...
being an everyday thing! It's really not that popular, or elaborated upon.


As Ben pointed out, you don't start from scratch when writing a "little language". You start with a generic language (like Ruby or Python or LISP), make up some new primitives (like go_around_the_block()), ignore any primitives which you don't need, and end up with a slang dialect which fits your problem space. It's called "little" because it's embedded within another, larger language.

Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them.

Cameron Laird [link|http://groups.google.com/groups?th=6c6790175731d644&seekm=m66s52-91c.ln1%40lairds.us#link8|made this point] nicely just this morning on c.l.p.:
Next, Python thumps Java on readability and maintainability. While I don't yet know how to make an iron-clad objective case for this briefly, I'm utterly convinced that Python programs are significantly easier to read "six months later". This matters: much of teamwork is dealing with source code that one doesn't understand. Traditionalists promote Java as a statically-typed language, but this is just a distraction; Python's more graceful expressiveness leads to relatively more focus on correct algorithms and unit tests, while Java is relatively mired in syntax. Programming in Java feels too often like dealing with Java, whereas Python is a leader in letting developers think they're dealing with the application.
New On what makes it easy to do little languages.
Double plus agreement on the "little language" explaination.

Ruby "makes it easy" because you can override almost any primitive (even builtin types) to create the behavior that you want. Python doesn't allow you to override builtin types; you have to subclass them.

I've done several "little languages" in Ruby and although the primitive thing can help, the biggest aid in doing a little language in Ruby is its ability to control the execution of a block of code. I've used Ruby to define mini-languages to (1) control build processes ([link|http://rake.rubyforge.org|http://rake.rubyforge.org]), (2) define data base schemas, (3) define FSM state transitions ([link|http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118962|http://blade.nagaoka.../ruby-talk/118962]) and (4) build XML structures ([link|http://onestepback.org/index.cgi/Tech/Ruby/BuilderObjects.rdoc|http://onestepback.o...ilderObjects.rdoc]). In all cases it was the Ruby block that made the resulting mini-language natural and easy to use.

The builder example (#4 above) is particularly telling. The idea came from Groovy (another language that supports code block) and was insanely easy to implement in Ruby. I can imagine that doing it in Lisp would also be easy. But I've seen attempts to reproduce it in languages that don't support code blocks (e.g. Python at [link|http://users.binary.net/thehaas/cgi-haas/blosxom.cgi/comp/python/xmlbuilder.html|http://users.binary....n/xmlbuilder.html]) and the results have always been less than the original.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
New Good point.
Python comes closest to that by having first-class functions (meaning, you can pass them around as objects). But Ruby's blocks are still miles ahead. Of course, LISP macros take the cake in that department. ;)

Something else I thought of in the shower: dynamic languages win in the little language department because they allow the developer to express a concept in the most appropriate syntax/semantics. For example, you're not stuck implementing go_around(person, community.get_block(13)). By dynamically adding/trapping attributes, and by overriding/subclassing builtins, you can write (Python examples):


  • go_around(person, community.block[13]), or even

  • go_around(person, community[13])

  • person.go_around(community[13])

  • blocks(13, person)

  • community.blocks.13.tour(person)

  • person.morning_walk += blocks[13]



...etc., any of which "does the same thing". This allows the designer to make a "little language" which is easier to use and extend. If you like TIMTOWTDI, you could implement them all simultaneously (but you probably shouldn't).


The Sig:
"Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either)."

Tim Peters on python-dev
New Orthogonal to DB usage
I agree about the "little language". However, I have not seen OOP do that better than procedural, and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted that pretty well. Sometimes one can use a combination of SQL and "custom language" routines. Example:
\n  func displayEmployees(criteria) {\n    sql = "SELECT * FROM emp,other_tables WHERE "\n    sql .= " [join stuff] and (" . criteria . ") ORDER BY foo"\n    rs = query(sql)\n    while (row = getNextRow(rs)) {\n      do_stuff_with_row(row)\n    }\n  }\n

Now we can pass it a boolean criteria expression to filter our rows. It is tough to do these kinds of things with "flat" API's. Plus, one can develop and test it as SQL first, and then paste it into the routine.
________________
oop.ismad.com
New That's actually a good idea
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function. Ooh, and you could also handle escaping user-input values in one location instead of re-creating it everywhere.

Oh wait, that's what I do with my -- as I said above -- DB object. Or did you think OO proponents had never thought of dynamically building their SQL?
===

Implicitly condoning stupidity since 2001.
New *Snork* beat me to it :)
New Cure worse than the medicine.
Then all you'd have to do is put the dynamic query building into a method of your DB object so you don't have to re-write the [join stuff] and (" . criteria . ") piece for every function.

Don't need OOP to do that. However, putting wrappers (OO or procedural) around SQL tends to bloat up code so that you have no net savings in code size.

Or did you think OO proponents had never thought of dynamically building their SQL?

Doing and making life easier can be two very different things.


________________
oop.ismad.com
New "tends to bloat up code"
[link|/forums/render/content/show?contentid=156638|Post #156638]
I withdrawl the "bloated" claim for now.

[link|/forums/render/content/show?contentid=156690|Post #156690] might be of interest to you, as well:
I have no doubt that you'll sit on this for a while and then trot out, "youses never proved it wasn't bloated!" at some point in the future, so I'm calling pre-foul now so it doesn't happen.
Backtracking again, Bryce...?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Your "solution" to such bloat was HQL, yes or no?
________________
oop.ismad.com
New It was a solution, yes.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Since you seem to be slow...
Scott's point is that you had this battle. Many times. You've lost. You've even admitted defeat.

Unless you have something truly novel to say, please save everyone time and energy by letting it drop this time.

Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New I did NOT "lose". His solution was variation on SQL
and NOT OOP
________________
oop.ismad.com
Expand Edited by tablizer Nov. 5, 2004, 05:00:11 PM EST
New In your universe, perhaps
His solution was variation on SQL and NOT OOP

Let me go back to [link|http://z.iwethey.org/forums/render/content/show?contentid=156638|http://z.iwethey.org...?contentid=156638] and see.

Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.

Once again you're talking out of your ass and hoping that none of us will catch where you're fudging the truth. Once again your hopes are misplaced. Please go away and try this elsewhere.

Thanks,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New The mapper did not reduce his code size
Ah yes. Right. Scott was talking about an object-relational mapper. Which means that the overall example is going to involve a lot of OOP.

It was not the mapper that allowed him to shorten his queries. Again, just because something exists does not necessarily mean it is better.

Plus, how come you cannot use your techniques to shorten challenge #6?
________________
oop.ismad.com
Expand Edited by tablizer Nov. 5, 2004, 05:16:02 PM EST
New Bryce, you lost this one already.
I'm not going to continue this discussion. I have a job, and I have work that needs to get done. This conversation has happened before, and you've lost. Repeatedly and decisively.

If you wish to read this as, "Bryce has more free time than Ben" you'd be perfectly correct. I'll let you waste someone else's time if anyone is interested.

Regards,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New I did NOT fscken lose. He gave no code-size proof. Zilch.
You guys have a warped sense of evidence. Did you flunk science class?
________________
oop.ismad.com
Expand Edited by tablizer Nov. 5, 2004, 07:15:01 PM EST
New Why is code size your (apparently) sole criterion?
Is it because that's the "best" metric? Please show your proof.
===

Implicitly condoning stupidity since 2001.
New You are welcome to present ANY metric you can justify
The common common metrics that people more or less agree on are:

* Once and only once - ridding duplication

* Easier to change - change scenarios are given and the impact on code is analyzed

* Code size - less code is generally better

I am not saying these are necessarily the best or most complete, but they are the easiest to analyze and communicate about up to this point.
________________
oop.ismad.com
New Thank you
I asked for proof of the value of your metric.

You replied that it's common and people more or less agree.

So popularity is your criterion.

OOP is popular.

Therefore, OOP is good.

Thank you for this admission of defeat.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Usually people don't question those much
If you have some better ones, then please describe them.
________________
oop.ismad.com
New We've already been over change scenarios
Re-read the thread. You gave up on the change metric because of the branching and source code control issues.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New re: We've already been over change scenarios
You gave up on the change metric because of the branching and source code control issues.

"Branching"? I am not sure what you are refering to. Version branching or flow logic branching?

As far as version management, the existing tools are biased toward files. I agreed to that fact. However, that is not an inborn inherent fault of tables, which was my point above.
________________
oop.ismad.com
New "Orthogonal" in exactly the same sense as differential gears
I agree about the "little language". However, I have not seen OOP do that better than procedural...


I have. 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.

...and second SQL is generally a pretty compact language. It is hard to beat it on code-size (even though SQL stinks in many ways). Jones' study hilighted [sic] that pretty well.


SQL is compact because you need further code to process its results, translating those results into usable structures--this is the "do_stuff_with_row" which you conveniently left out. By mixing SQL directly into your application language (whether "procedural" style or "object-oriented"), you force the developer to manage two languages at once, manually handling the translation step between the two every time they make a choice about development. A good ORM hides that, freeing the developer to focus on the problem domain.

Sometimes one can use a combination of SQL and "custom language" routines. Example:

func displayEmployees(criteria) {
sql = "SELECT * FROM emp,other_tables WHERE "
sql .= " [join stuff] and (" . criteria . ") ORDER BY foo"
rs = query(sql)
while (row = getNextRow(rs)) {
do_stuff_with_row(row)
}
}

Now we can pass it a boolean criteria expression to filter our rows.


OOP: Great! You've just introduced a security hole by manually interpolating strings.

TOP: Oh, but we'll never pass it unsafe criteria.

OOP: And that's documented/enforced where, exactly?

TOP: Fine, we'll add a comment in the procedure, documenting exactly what is considered "safe" criteria.

OOP: Good. But you've got a staff of 10 developers. Who's got time to read each others' embedded comments in a library call?

TOP: Fine (adding a line or two of code), we'll enforce it within the procedure.

OOP: Wonderful! You missed a spot.

TOP: Fine (another 10 lines of code).

OOP: OK. Now do that in *every* procedure with embedded SQL.

TOP: Fine, we'll abstract that into an "SQL checker" tool (adding 1000 lines of code).

OOP: Nice! You've just written an SQL parser/validator. But you slowed down your DB I/O by a factor of ten (or more).

TOP: Fine, we can speed that up greatly by validating each component *before* we construct the SQL string. We just need a little extra structure to say "this atom is the tablename" and "this atom is a boolean criteria string" and "this atom is the ORDER BY clause".

OOP: Hmmm. It works, but you've got this huge bottleneck procedure with 38 arguments.

TOP: No, I reworked it last night. Now I have 74 different procedures with slightly different argument lists for every occasion.

OOP: Oog. That's really confusing. Can't we build our list of SQL atoms incrementally? Maybe there's some way to collect all those components into a single structure and then just pass that.

TOP: Fine. I worked 20 hours a day for 2 weeks, but it's done: a module which builds safe SQL strings out of potentially unsafe components, and it's developer-friendly. Happy now?

OOP: Congratulations. You've just written your first ORM.

It is tough to do these kinds of things with "flat" API's.


It's tough regardless. Why not let a team of experts do the tough parts once and let everyone benefit?

Plus, one can develop and test it as SQL first, and then paste it into the routine.


I'd rather have a complete test suite. Did you test the corner cases? Did you test malformed data? Did you test code coverage? Unless you've found (or written) a complete testing framework/harness within your database as well... in which case, my hat's off to you. But I haven't seen one yet.

TOP may be fine for developers who have never worked on anything other than a small project, who care nothing for portability, maintainability, or software engineering (as opposed to software construction). Which is fine--lots of code is of the home construction type, where you build a small one-story edifice, live in it for life, and patch as you go. It's an asset on the books, and depreciates. Just don't expect it to give your corp a competitive advantage--that requires engineering, design, and risk management. Embedding SQL in procedural code is two-by-fours and drywall, and lots of paint. A good ORM and good OO design is pre-stressed steel, trusses, sunken piles, shear walls, and an interior designer.


The Sig:
"Despite the seemingly endless necessity for doing
so, it's actually not possible to reverse-engineer intended invariants
from staring at thousands of lines of code (not in C, and not in
Python code either)."

Tim Peters on python-dev
New You just shortened this thread by 200 posts. Cut & Paste.
Congratulations! :-D

We'll have to come up with another non-election related topic.

Hmmm....

How about: [link|http://discuss.joelonsoftware.com/default.asp?design.4.20066.21|Is Cut and paste a Bad Design] at Joel on Software.

That [Jef Raskin] is a crackpot out of touch with reality is clear from the above article where he complains that features like cut and paste don't work, are useless, and contribute to code bloat. His argument is that if you walk away from your computer for an hour after cutting, you might forget you had cut and planned to paste and your work that was cut would be lost forever. I do believe that this has happened to him frequently because he is losing his mind. Like, whatever. Cut and paste to be working for everybody else on the planet. I think it works OK and taking it out would not improve things much.


Cut and paste isn't something I think about much any more. Every editor I've used has had it.

Having more access to the clipboard where things are held transiently is a good idea and would solve his problem of losing track of things. [link|http://hobbes.nmsu.edu/pub/os2/util/clipbrd/mgclip02.zip|MegaClip] was such a tool on OS/2 (from the readme.txt):

MegaClip is a utility to manage multiple OS/2 PM clipboards. It is inspired in part by the IBM EWS program "ManyClip", as well as by a Windows 3.1 program I used Looong ago (but have forgotten the name of now). MegaClip's key feature over ManyClip is its ability to handle bitmaps and metafiles in addition to text. Other benefits include the ability to view more than one clipboard at a time (multiple windows), to view details about the clip (date, time, size, etc), and to 'hold' one clip in the system clipboard -- even while copying other clips. Clips may be stored within the main program window or placed directly on the desktop and it is possible to turn off 'Auto-Retrieve' so that only desired clips are retained. These features are briefly explained below.


I don't think Cut & Paste is the issue. You?

Cheers,
Scott.
New "[Nobody] ...points out that the cut-and-paste method...
...of moving text is inherently faulty."

Nobody, that is, except Microsoft. Jef might be forgiven for only using Macs, and never experiencing Explorer's default cut-and-paste behavior, wherein, if you never paste a "cut" file, it never gets completely "cut". Or Excel, wherein, if you never paste a "cut" row, the original is never deleted.

Meh. Mr. Raskin is a smart guy, and I greatly enjoyed Humane Interface, and learned a lot. Everyone's entitled to bad ideas. "...test the spirits to see whether they are from God, because many false prophets have gone out into the world."
New 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.)
________________
oop.ismad.com
Expand Edited by tablizer Nov. 4, 2004, 10:46:13 PM EST
     Time for good anti-OO battle to take minds off of election - (tablizer) - (77)
         Sorry cant go there - (daemon) - (32)
             How is being locked to a DB more evil than being locked to - (tablizer) - (31)
                 It's best to fit the tool to the job - (FuManChu) - (30)
                     Thanks for that ... +5 insightful - (drewk) - (6)
                         For various definitions of "start" ;) - (FuManChu)
                         On writing the "little language thing ..." - (systems) - (4)
                             Suggestion - (ben_tilly)
                             "Little Language" definition, components - (FuManChu) - (2)
                                 On what makes it easy to do little languages. - (JimWeirich) - (1)
                                     Good point. - (FuManChu)
                     Orthogonal to DB usage - (tablizer) - (22)
                         That's actually a good idea - (drewk) - (17)
                             *Snork* beat me to it :) -NT - (FuManChu)
                             Cure worse than the medicine. - (tablizer) - (15)
                                 "tends to bloat up code" - (admin) - (14)
                                     Your "solution" to such bloat was HQL, yes or no? -NT - (tablizer) - (13)
                                         It was a solution, yes. -NT - (admin)
                                         Since you seem to be slow... - (ben_tilly) - (11)
                                             I did NOT "lose". His solution was variation on SQL - (tablizer) - (10)
                                                 In your universe, perhaps - (ben_tilly) - (9)
                                                     The mapper did not reduce his code size - (tablizer) - (8)
                                                         Bryce, you lost this one already. - (ben_tilly) - (7)
                                                             I did NOT fscken lose. He gave no code-size proof. Zilch. - (tablizer) - (6)
                                                                 Why is code size your (apparently) sole criterion? - (drewk) - (5)
                                                                     You are welcome to present ANY metric you can justify - (tablizer) - (4)
                                                                         Thank you - (drewk) - (1)
                                                                             Usually people don't question those much - (tablizer)
                                                                         We've already been over change scenarios - (admin) - (1)
                                                                             re: We've already been over change scenarios - (tablizer)
                         "Orthogonal" in exactly the same sense as differential gears - (FuManChu) - (3)
                             You just shortened this thread by 200 posts. Cut & Paste. - (Another Scott) - (1)
                                 "[Nobody] ...points out that the cut-and-paste method... - (FuManChu)
                             No, you got me all wrong, dude - (tablizer)
         Repeat after me: - (admin) - (1)
             I never said OO was JUST about inheritance. - (tablizer)
         Amusing to note... - (JimWeirich) - (41)
             re: nouns and noun grouping - (tablizer) - (40)
                 Bryce: control tables are bad - (admin) - (37)
                     Time will erase performance differences - (tablizer) - (36)
                         That's not the main reason why they're bad. - (admin) - (35)
                             Because VC tools are hierarchy-biased. - (tablizer) - (34)
                                 Go read the thread. - (admin) - (33)
                                     You always talk as if I push a grand conspiracy - (tablizer) - (32)
                                         Relational has its place. - (admin) - (31)
                                             Math and Boolean expressions - (tablizer) - (30)
                                                 Ever use Zachary? - (admin) - (29)
                                                     I will believe it only when I see it with my own eyes - (tablizer) - (28)
                                                         - said the blind man (ducks and runs) -NT - (Arkadiy)
                                                         NO. - (admin) - (26)
                                                             You never identified an in-born fault of tables. -NT - (tablizer) - (25)
                                                                 Tables don't make good chairs. - (Another Scott) - (24)
                                                                     Vacuum Tubes - (tablizer) - (23)
                                                                         You can pry my tube guitar amp outta my cold, dead fingers. - (Steve Lowe) - (22)
                                                                             Digital precision can be boring - (tablizer) - (18)
                                                                                 Yes - tubes are IT man - (tuberculosis) - (17)
                                                                                     Heh! That was my first bass amp! - (jb4) - (16)
                                                                                         I don't know whether to be amused or appalled - (tuberculosis) - (15)
                                                                                             Both actually - (jb4) - (14)
                                                                                                 In negotiations - (jake123) - (13)
                                                                                                     Drooooooooool - (Steve Lowe) - (12)
                                                                                                         Didn't get it - (jake123) - (11)
                                                                                                             Bum R! -NT - (jb4) - (10)
                                                                                                                 Oh well. - (jake123) - (9)
                                                                                                                     Talk to your amp tech - (Steve Lowe) - (8)
                                                                                                                         Oh yeah - (jake123) - (1)
                                                                                                                             Had a teacher who did that - (drewk)
                                                                                                                         Re: Talk to your amp tech - (Ashton) - (5)
                                                                                                                             What I'm gaining - (jake123) - (4)
                                                                                                                                 Have you considered an attenuator? - (Steve Lowe) - (3)
                                                                                                                                     Yes I have - (jake123) - (2)
                                                                                                                                         New thread time, maybe...? -NT - (admin)
                                                                                                                                         This might not cost a bundle.. (new thread) - (Ashton)
                                                                             Mesa Boogie Forever -NT - (tuberculosis) - (2)
                                                                                 That'll prolly be my second choice - (jake123)
                                                                                 Feh! The Ultimate was... - (jb4)
                 re: nouns and noun grouping - (JimWeirich) - (1)
                     Can't do a whole lot with your hidden anecdotes - (tablizer)

UNAPOTHEGMATIC MAN
177 ms