Personally I'm very happy with internalized re-linq. As we have a configurable HQL-Translator I would have even a configurable INhQueryProvider
On Tue, Apr 12, 2011 at 1:09 PM, Patrick Earl <[email protected]> wrote: > You're right Stefan. I've been thinking about it more recently. At > the moment, I'm considering the following alternatives: > > 1. Just expose types that are specifically required for some purpose. > 2. Only internalize Antlr, don't internalize ReLinq. > 3. Change the namespace of all classes from Remotion.Linq to > NHibernate.Remotion.Linq to avoid conflicts. > > IMHO, #3 would be ideal from a user perspective, but it's also more > difficult to implement. #1 leads to more work since we need to expose > types as needed, making many decisions there. #2 is easy, but then > users take on the full risk of changes themselves. I'm currently > leaning towards #2, though I'm naturally happy to hear other people's > thoughts. It fits better in my head with my "everything should be > open" ideal. > > Patrick Earl > > On Tue, Apr 12, 2011 at 4:49 AM, Wenig, Stefan <[email protected]> > wrote: > > Hi Patrick > > > > I think you're trying something impossible here. If you expose re-linq's > types, you have a dependency. Just making a base class internal and carrying > every single protected method forward won't solve the problem. If there > really is a change, you're not very likely to be able to hide it from your > downstream users using this extremely thin layer. The coupling is already > there. > > > > You'd have to create a much more verbose structure to effectively > decouple your users from re-linq. That would exclude deriving any public > types from our types. In the end, you'll have reinvented the extensibility > of re-linq. But what for? > > > > re-linq already has the extension system your users need, and more. You > just need to make sure that the required parts are accessible through the > façade that NH puts around it, and you get a well designed, powerful > extensibility pipeline for free. > > > > And we're trying to avoid breaking changes too. The last round of changes > was done to serve NH, and now we have 2 major providers (NH and our own > re-store) building on re-linq, and a few less visible providers, and it > works well for all of them. We believe it's very stable now, and none of the > plans we have for re-linq will break it. Why would an extensibility pipeline > in NH be able to strike a better balance between improvements and backwards > compatibility? > > > > (The namespace change was an exception, and we only did it because we > knew the downstream effects would be pretty tiny. Few people affected, > little work to do, no risk of introducing bugs.) > > > > Also, I have to say that deriving a public type from an internal type via > IL modification is a hack. There's a reason C# won't let you do this. > > > > Bottom line: I would keep ILMerge, but remove the /internalize option. > Any user who seriously customizes LINQ parsing should be advanced enough to > realize they're dealing with another namespace, therefore creating a > dependency to a 3rd party library here. And like I said, there's not really > a versioning problem here that needs solving either. > > > > Cheers, > > Stefan > -- Fabio Maulo
