Java vs Go: Impressive Solutions for Invented Problems
jawher.me2 pointsby jawher0 comments
[-R [-H | -L | -P]] [-fi | -n] [-apvX] SRC... DST
With a parser combinator based approach: and(
optional(and('-R', or('-H', '-L', '-P'))),
optional(or(
'-fi',
'-n'
)
),
optional('-apvX'),
repeatable('SRC'),
'DST')
And this didn't even handle the fact that options order is not important. Thread.currentThread().getStacktrace()
Which will return an array containing all the info you'd like, with method names, line numbers and file names. var True = function(){};
var False = function(){};
var getBool = function(b, ifTrue, ifFalse) {
return (function() {
if(b instanceof True) {
return ifTrue;
} else if(b instanceof False) {
return ifFalse;
}
})();
}
The Closure compiler generates: var True = function() {
}, False = function() {
}, getBool = function(b, c, d) {
var a;
b instanceof True ? a = c : b instanceof False && (a = d);
return a
}; select first_name, last_name, login, email from users where id = 5;
Depending on the language and ORM you use, you'll need to write code that resembles this: result = execute(query);
User u = new User();
u.firstName = result.get("first_name);
u.lastName = result.get("last_name);
u.login = result.get("login);
u.email = result.get("email);
The mapping part may also involve data conversion between SQL types and you language types. > This doesn't seem like an insoluble problem; rather than use an ORM to generate an impenetrable glue layer, it would be better to use code generation tools to create a clean database model and a glue layer that can be easily overloaded as required.
Glad you brought that up. I too thought about this as a middle ground solution between "boring your self to death by writing dozens of SQL queries and hand mapping to your model" and "black box ORM that generates crazy SQL queries". update table set where some_condition_on_another_field.
How would you expect an ORM to generate a "dense" query like this with it's simplistic view of things ? obj.method((Runnable)(()=> println("oh hai !"))); Function<Void>
It's a bit shady though as you still have to return a value from the body of the method, and that value has to be null. Function0<Int> f = () => 5
f here is a lambda that take no args and returns an Int. It's type is Function0 (0 for no args) and parameterized with the return type. Function2<String, Float, Int> f = (String name, Float rate) => 5
The Function* types are the generic structural types able to describe lambdas. C# has them, and so does Scala. public <S> List<T> stupidOpName(Function1<T, S> f) { ... }
public List<T> stupidOpName(Function1<T, Boolean> f) { ... }
After erasure, we'll end up with : public List stupidOpName(Function1 f) { ... }
public List stupidOpName(Function1 f) { ... }
i.e. 2 methods with the same name and same signature. This is bad. You don't ever want that to happen. And fortunately the java compiler won't let it happen. Runnable r = () => { ... }
The lambda gets converted to the Runnable type.
Disclaimer: I'm the author of mow.cli ;)