Re: approaches for embedding a data language in a general purpose language

> I haven't yet seen an OR/M that didn't strike me as something
> akin to those little inflatable duck rings you put on kids to get them
> used to the pool.

I love this analogy!

> They push the programmer hard in the direction
> of thinking in terms of "get the data back from the dbms; turn it in
> to objects; modify those objects; update" even though that approach
> is not typically the right choice.

Exactly.

LINQ is better, in this regard, though the new ADO.NET v3 O->RM framework that is layered over it seems to be a typically flawed O->RM implementation.

To implement LINQ Microsoft extended C# to support anonymous tuple types, so it is possible in LINQ to just write the query to get the data you want and get the data back in a typesafe manner.

The LINQ query syntax is still horribly SQLy, with some OQLism thrown in, and it retains NULL, 3VL. I _think_ (though I'm not sure) that the intent at least is to have decent updatable view support, which is something, I guess.

Unfortunately, while some of the features added to C# for LINQ are useful in other contexts (better lambdas, limited type inference, limited expression trees/currying), I don't think its possible to write your own DSL (for a TTM-style "D" sublanguage, for example) using those features. For example, AFAICT, you can't define a generic function JOIN that takes two (anonymous typed) tuples and returns another (correctly though anonymously typed) tuple which is the tuple-join result.

It _might_ be possible to do that in Managed C++ (I think ISO C++ template metaprogramming could provide the type deduction).

Misha Received on Tue Oct 10 2006 - 15:13:14 CDT