I'd stick with #2. #3 is not only more work, it also implies ownership of everything in re-linq. You begin the namespace with NHibernate and then watch people asking questions about re-linq here, complaining, asking you for changes. If you make it clear that this is not NH, it's everyone's own choice whether digging deep is worth the dependency on another project.
Cheers, Stefan > -----Original Message----- > From: [email protected] [mailto:nhibernate- > [email protected]] On Behalf Of Patrick Earl > Sent: Tuesday, April 12, 2011 6:09 PM > To: [email protected] > Subject: Re: [nhibernate-development] ILMerge > > 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
