Because that would only end up creating more confusion. On Mon, Apr 20, 2009 at 10:35 AM, mjcoder <[email protected]> wrote:
> > I'm also just a user and would prefer using the new AST parser > (because it allows DML statements). However, why don't you create two > downloadable packages? One with the old parser as default and one with > the new parser as default and let the downloader decide? > > On 17 Apr., 22:22, Fabio Maulo <[email protected]> wrote: > > And which is the difference with have the new AST parser as default ?I > > mean... > > "if you want to get the OLD parser...." > > > > IMO the scenario should be: > > A team download the new version, they have the new AST parser working by > > default. > > The team run all tests in their development environment, if all is > working > > they will do the same in production (or QA etc.). > > > > 2009/4/17 Matt <[email protected]> > > > > > > > > > > > > > I'm just a users here... > > > > > IMO, having new code like this set as the default parser is risky. I > > > don't see a problem keeping the default parser for now. Most on-the- > > > edge teams will switch over to the new parser anyway, but those who > > > are unsure or frankly don't know anybetter won't be open to the > > > possibility of new bugs in their production code. Of course, moving to > > > new versions of anything opens you up to bugs. > > > > > If you want to get the new parser "battle-hardened", I'm sure most > > > groups will switch to it in their development environemnts and once > > > their sure it works, they'll do the same for production. > > > > > +1 for keeping the classic parser default (for now) > > > > > On Apr 17, 7:34 am, "Richard Brown \(GMail\)" > > > <[email protected]> wrote: > > > > Just wanted to add my 2 pence to the discussion ... (sorry if it's > not > > > appropriate) > > > > > > +1 on making the AST the default parser for 2.1GA because ... > > > > > > 1. I'm not sure there are sensible criteria that I (as a user) can > apply > > > to choosing the parser, other than that the NH tests pass/fail (or my > > > system's tests pass/fail). Asking me which (in general) should be > default > > > is not something I have enough information to decide; > > > > > > 2. From developing code on the NH side of things, I'm not sure I > value > > > correctness over maintainability. I would rather have clean > maintainable > > > code with a couple of bugs (cos that's easy to fix), than have mostly > stable > > > code that's hard to fix bugs in or enhance. Having glanced at the AST > code, > > > it seems infinitely easier to maintain (specifically I was looking at > query > > > parameters where the AST stores them (correctly) in the query, while > the > > > existing parser has them spread out in various bits of the code) - > > > ultimately I think that's the best criteria to use, making it the > obvious > > > choice for the default. > > > > > > 3. If the tests are all going to run with the AST parser, that makes > > > supporting the legacy one harder (which compounds point 2). > > > > > > And of course ... all of this is just my humble opinion. > > > > > > Cheers, > > > > Richard > > > > > > From: Fabio Maulo > > > > Sent: Thursday, April 16, 2009 6:39 PM > > > > To: [email protected] > > > > Subject: [nhibernate-development] Re: HQL AST Parser > > > > > > 2009/4/16 Hadi Hariri <[email protected]> > > > > > > No I haven't tried it yet. I mentioned that we can port two of our > apps > > > to use the new parser, but haven't yet. > > > > > > don't worry before have a problem to be worried; the software can be > > > fixed ;) > > > > I'll try the new parser with some real-world application too. > > > > -- > > > > Fabio Maulo > > > > -- > > Fabio Maulo >
