It is a bad idea to have an
$htmlEncode feature in your database querying function.
One reason is to adhere to the general maxim that every function should have one purpose, and only one purpose. That conventional wisdom is good advice, though I'm not sure how to make it sound convincing. You'll just have to take my word and try it. There are other reasons, though.
It's much simpler to adopt a strategy of keeping all strings in the most natural form, then escape them just at the point of use. If you HTML-escape some strings in advance, then it will be a headache keeping track of which strings have already been escaped, and which ones haven't. You could use some form of Hungarian notation to help you keep track, but it's best to avoid the problem altogether. Instead, if you stick with the policy of storing unescaped strings in all variables, then code in your HTML template that looks like
<?php echo Reform::HtmlEncode($string); ?> is obviously correct by inspection. For that reason, it is worth cluttering your HTML template with encoding calls everywhere, though you might want to create an alias to shorten
Finally, escaping HTML in your database layer is reminiscent of the PHP Magic Quotes fiasco. The PHP developers thought it would be a good idea to prevent SQL injection by making it easy to automatically insert backslashes before all "unsafe" characters. In practice, that design led to all kinds of data corruption, and programmers had to undo the weirdness with
stripslashes(), all because the data was being escaped at the wrong layer. Learn from that mistake: you need to apply the appropriate escaping and unescaping at the appropriate layer, and there is no good shortcut to avoid doing it the right way.