Mysql - transforming non-null values part 2 - mysql

In this question I asked if Mysql have a function which receives two arguments and returns null if the first is null or the second argument otherwise. Somebody said in the comment section that such function doesn't exist. How can I define this function in Mysql, considering that it may receive arguments of any type and the return value can be null or of the same type of the second parameter? Is it even possible?

This is not possible, given your or requirements.
The arguments and return values of stored functions (written in SQL) and user-defined functions (written in C) are all statically typed.
Granted, MySQL is pretty flexible with implicit casting, but the values are typed nonetheless. Even if you were okay with implicit casting, a scenario where that would be preferable to the seemingly-obvious solution is difficult to imagine.
IF(foo IS NULL,foo,bar) would suffice for the purpose and preserve the underlying types correctly, and IF(foo IS NULL,NULL,bar) would be almost the same thing, though the type of foo would be lost (e.g a "it's a NULL DATETIME").
You have previously rejected those, for reasons that are not intuitively obvious. When a purpose can be accomplished with built-ins, the motivation to reinvent the wheel is hard to understand.

try this:
Select IF(ISNULL(arg1), null, arg2)
Read more about Comparison Functions and Operators and Control Flow Functions.

Related

Term for function parameters defined for generic use, not specific

Is there a term for this technique? One prominent example is the WinAPI: SendMessage( hwnd, msg, info1, info2 ) where parameters #3 and #4 only make sense per msg (which also means there are cases when only one or none of those two parameters are needed). See MSDN.
Rephrased: having an all-purpose function that always accepts multiple arguments, but interpreting them depends on a previous argument. I don't want to talk about open arrays, open arguments, typeless arguments... I know all that. That's not what I'm asking - I want to have the term for this type of functions (any maybe also how unspecific parameters are called).
This is not about casts or passing by reference - the parameter types are always the same. Other example: calculate( char operation, int a, int b ) which is then used as
calculate( '+', 2, 5 ) (parameters #2 and #3 are summands)
calculate( '/', 4, 2 ) (parameter #2 is the divident and parameter #3 is the divisor)
calculate( '!', 3, 0 ) (parameter #2 is the factorial and parameter #3 is unused)
In all these cases the data type is always the same and never casted. But the meaning of parameters #2 and #3 differ per parameter #1. And since this is the case it is difficult to give those parameters a meaningful name. Of course the function itself most likely uses a switch(), but that is not subject to my question. How are parameters #2 and #3 called, where a distinct name cannot be found, but data types are always the same?
The fact the msg argument "changes" the parameters is through a simple switch statement. Each "msg" in the switch knows the parameters(with type) needed and casts them appropriately.
This "technique" is called passing by reference, or passing by address. The latter is usually used for method pointers.
There is no Special name if that is what you are asking. It is a regular function, method or procedure.
The referenced Function is a Win32 API Function, which may be referred to as a "Windows function call."
This is an example of a static Parameter and multiple Dynamic parameters.
The static is the "msg" and the dynamic is described as the following:
These parameters are generic pointers. Passed by reference. They can point to any data type or no value, ie null pointer. It is up to the sender to lock the memory in place, and the receiving method to interpret the pointer correctly (through pointer casts).
This is an example of typeless argument passing. The only thing passed is a memory address. It is dangerous since the types passed must be agreed upon ahead of time(by convention and not contract as with a typed language construct) and must match on both sides of the call.
This was common before C++, in the C days, we only had C structs to pass around. Leading to many General Fault Protection errors. Since then, typed interfaces mostly have replaced the generic equivalents through libraries. But the underlying Win32 methods remain the same. The main substantial change since its' inception is the acceptance of 64-bit pointers.
Although not widely supported, what you are referring to would be a dependently typed function (or dependently typed parameters).
To quote wikipedia on dependent types
A "pair of integers" is a type. A "pair of integers where the second is greater than the first" is a dependent type because of the dependence on the value.
The parameters could have a type that depends on a value. The type of info1 depends on the value msg as does info2.
In order to make this approach work in a language without dependent types, the dependent parameters are given a very generic type that is only refined later on when more information is available. When the type of msg becomes known (at runtime) only then is are the types of info1 and info2 assumed. Even though the language doesn't allow you to express this dependency, I would still call the approach a dependently type one.

Why is the return function called return?

Why is the return function called return?
The description is:
Inject a value into the monadic type.
The name not only doesn't make sense (to me), it is confusing for people coming from an imperative language where return is a language keyword that returns from the function.
Why is it called that? Because it's usually the very last function in a monadic block of code. Usually the only good reason to use return is to set the final return value from your monadic action.
I too think that this is a very, very poor name choice. But it's not like we can fix it now...
It's purely historical. Most Haskell developers agree it's a bad name. It breaks the principle of least surprise. Quite a few of the older library functions are a bit wonky (the plethora of error handling schemes and a few other typeclass element names come to mind).
As #bheklilr says, there is a restructuring underway which should help:
http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
These are good places to start if you are interested in the meta of Haskell:
http://www.haskell.org/haskellwiki/Future_of_Haskell
http://www.haskell.org/haskellwiki/Category:History
The answer is because it returns something. It you use in PHP for example - echo something in it, it returns that text or data. But functions primary power is not in echoing data directly. Their power is in storing data and returning variable/array or similar where are data is stored.
You can also return true or false based on data/calculation. In classes, functions are named methods and do the same thing - return something. In java return can be void (echoed data), or strict data type (boolean for example, or String, Array, etc).
After return function data is not being returned.

Is there a term for a function that modifies its arguments?

I'm not really classically educated in CS or mathematics. I'm just thinking there should be a term for this in pass-by-reference laungauges such as php. IE. functions that return a result (like how you'd want most functions to work) versus functions that modify an in-parameter.
Is there such a term?
The only term that I have heard relating to what you are talking about is: parameter idempotence
Simply put this type of function guarantees that the arguments remain untouched.
As far as a function that changes parameters I haven't heard any particular terms but I just say: parameter mutating.
From my experience any function that takes a reference to an object, it's a fairly safe bet that it will be mutating that parameter in some way.

What are better ways to create a method that takes many arguments? (10+?)

I was looking at some code of a fellow developer, and almost cried. In the method definition there are 12 arguments. From my experience..this isn't good. If it were me, I would have sent in an object of some sort.
Is there another / more preferred way to do this (in other words, what's the best way to fix this and explain why)?
public long Save (
String today,
String name,
String desc,
int ID,
String otherNm,
DateTime dt,
int status,
String periodID,
String otherDt,
String submittedDt
)
ignore my poor variable names - they are examples
It highly depends on the language.
In a language without compile-time typechecking (e.g. python, javascript, etc.) you should use keyword arguments (common in python: you can access them like a dictionary passed in as an argument) or objects/dictionaries you manually pass in as arguments (common in javascript).
However the "argument hell" you described is sometimes "the right way to do things" for certain languages with compile-time typechecking, because using objects will obfuscate the semantics from the typechecker. The solution then would be to use a better language with compile-time typechecking which allows pattern-matching of objects as arguments.
Yes, use objects. Also, the function is probably doing too much if it needs all of this information, so use smaller functions.
Use objects.
class User { ... }
User user = ...
Save(user);
It decision provides easy way for adding new parameters.
It depends on how complex the function is. If it does something non-trivial with each of those arguments, it should probably be split. If it just passes them through, they should probably be collected in an object. But if it just creates a row in a table, it's not really big deal. It's less of a deal if your language supports keyword arguments.
I imagine the issue you're experiencing is being able to look at the method call and know what argument is receiving what value. This is a pernicious problem in a language like Java, which lacks something like keyword arguments or JSON hashes to pass named arguments.
In this situation, the Builder pattern is a useful solution. It's more objects, three total, but leads to more comprehensible code for the problem you're describing. So the three objects in this case would be as such:
Thing: stateful entity, typically immutable (i.e. getters only)
ThingBuilder: factory class, creates a Thing entity and sets its values.
ThingDAO: not necessary for using the Builder pattern, but addresses your question.
Interaction
/*
ThingBuilder is a static inner class of Thing, where each of its
"set" method calls returns the ThingBuilder instance being worked with
while the final "build()" call returns the instantiated Thing instance.
*/
Thing thing = Thing.createBuilder().
.setToday("2012/04/01")
.setName("Example")
// ...etc...
.build();
// the Thing instance as get methods for each property
thing.getName();
// get your reference to thingDAO however it's done
thingDAO.save(thing);
The result is you get named arguments and an immutable instance.

What is the name of a function whose result depends only on its parameters?

I'm writing a toy compiler thingy which can optimise function calls if the result depends only on the values of the arguments. So functions like xor and concatenate depend only on their inputs, calling them with the same input always gives the same output. But functions like time and rand depend on "hidden" program state, and calling them with the same input may give different output. I'm just trying to figure out what the adjective is that distinguishes these two types of function, like "isomorphic" or "re-entrant" or something. Can someone tell me the word I'm looking for?
The term you are looking for is Pure
http://en.wikipedia.org/wiki/Pure_function
I think it's called Pure Function:
In computer programming, a function may be described as pure if both these statements about the function hold:
The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.
The result value need not depend on all (or any) of the argument values. However, it must depend on nothing other than the argument values.
I guess you could say the adjective is "pure" if you go by "pure function".
I always learnt that a function whose output is always the same when the arguments are always the same is called "deterministic". Personally, I feel that that is a more descriptive term. I guess a "pure function" is by definition deterministic, and it seems a pure function is also required to not have any side-effects. I assume that that need not be the case for all deterministic functions (as long as the return value is always the same for the same arguments).
Wikipedia link: http://en.wikipedia.org/wiki/Deterministic_algorithm
Quote:
Given a particular input, it will always produce the same output, and the underlying machine will always pass through the same sequence of states.