On 2011-10-11 23:31, Andrei Alexandrescu wrote:
On 10/11/11 3:05 PM, Jacob Carlborg wrote:
If we're talking use cases and high level interfaces I would go with
something like:
[snip]
I recommend that everyone take a good look at ActiveRecord in Ruby on
Rails:
http://guides.rubyonrails.org/active_record_querying.html
http://guides.rubyonrails.org/association_basics.html
http://guides.rubyonrails.org/active_record_validations_callbacks.html
I confess the example you gave looks very foreign to me. From consulting
http://guides.rubyonrails.org/active_record_querying.html, I see Ruby's
active records esentially recode relational algebra in Ruby (as for the
constructs the equivalent SQL is shown).
For a variety of reasons, this would be tenuous in D. One simple reason
is that e.g. lambdas don't offer access to textual representation, which
would be necessary to translate lambda-based conditions into SQL text.
This is an example of how a lambda-based condition can be translated
into SQL:
module test;
import std.stdio;
import std.conv;
struct Result
{
string str;
}
struct Compare
{
string str;
Result eq (T) (T t)
{
return Result(str ~ " = '" ~ s ~ "'");
}
}
struct Table
{
Compare opDispatch (string name) ()
{
return Compare(name);
}
}
void where (Result delegate (Table) dg)
{
auto result = dg(Table());
writeln("where ", result.str);
}
void main ()
{
where((Table post){
return post.name.eq("foobar");
});
}
The above code will print "where name = 'foobar'".
Here I'm using the "eq" method instead of opEquals since opEquals
requires a specific signature.
--
/Jacob Carlborg
