Hot answers tagged

9

The issue is easier to understand if you consider carefully what it really means to overload a function. Overloaded methods e.g. in Java are really two completely separate entities; they share no byte code, no address, nothing except their name; and their name isn't really the same either, since in the compiler symbol table, a print() method for ints and a ...


2

Additional to other answers, there are dynamically typed languages where you can overload functions with different number of arguments (a.k.a "arity"). For example, there is erlang: add(X,Y) -> Z = X+Y, io:fwrite("~w~n",[Z]). add(X,Y,Z) -> A = X+Y+Z, io:fwrite("~w~n",[A]).


2

You're absolutely right not to take it for granted that a "best practice" is always in fact the best strategy. The important thing is to understand the reasons it's usually a good idea, and then make an informed decision whether those reasons apply to your case. Reasons it's usually a good idea to put as much filtering as possible on the database ...


2

There is a very good chance that evaluating the condition stops when the outcome is known. You have an expensive and precise filter, and a cheap and coarse filter. If you use the condition “coarse filter AND precise filter”, then you get the precise result, but the expensive filter will not be evaluated for everything, but just for the rows that pass the ...


1

It is absolutely fine to use the database as a coarse filter. Remember there it is hard to do unit tests of database code so we don't want the query to be too complex. If you are using most of the data you get back I think it's absolutely fine to ask for more data than you need. If you however ask for 5x-10x the data you actually need I would consider it a ...


Only top voted, non community-wiki answers of a minimum length are eligible