______________________________________
From: [email protected]
[[email protected]] on behalf of Frans Bouma [[email protected]]
Writing a linq provider takes a lot of dedication and focus, you
can't just 'jump in and provide a patch', that's not going anywhere. You
have to design the thing from start to finish, write tools to help you
develop the thing (like visualizers which view the various stages of the
expression tree), and implement the various stages. You however seem to
think it's a matter of 'someone will come up with a patch for <feature> /
<bug>'. No way in hell that that's going to work for the linq provider.
Frans, if you want to understand the dynamics of development here you'll have
to take a look at the code. Writing a LINQ provider based on re-linq is a very
different endeavor than starting from scratch. You did it the Matt Warren way,
basically, right? With re-linq, you get a nice AST and some tools. No
IQueryable-based expression tree, no transparent identifiers, etc.
And I understand that HQL is closer to LINQ than SQL is to LINQ, so some
transformations are simply not necessary. I think the hardest part is designing
how a certain LINQ expression should be translated to HQL - that's why I keep
insisting on the HQL output for diagnostics. (Now that's just theory, and I'm
sure Steve can tell us about some monumental problems he had to solve, but I
still think that you can't judge the accessibility of that code from your own
experience. The parts of the LINQ2NH code that I looked at don't look that
frightening after all, and that's a good thing!)
Long story short, I believe that once you understand what transformation the
code is trying to achieve, any good coder should be able to create a little
patch.
