Steve, Do we even need to make activate the new parser in order to use it? I would assume that we can use the classic parser and still take advantage of AST to query support, no?
On Wed, Apr 15, 2009 at 11:07 AM, Steve <[email protected]> wrote: > > My call is that it shouldn't work. In .Net, you can't compare two > types that are different. Just because the Id's happen to match > doesn't imply equality in any way, IMO. Being forced to add the .Id > (as in e.Reverse.id = a.Forward.id) makes the developer's intentions > clear. > > Note that if the types match, then the .Id isn't necessary. So > "e.Reverse = e.Reverse" is absolutely fine (poor example, since it's a > tautology, but I'm sure you get the point!). > > Whether we're happy to take a breaking change is another issue. My > feeling is that the new parser should *not* be the default, that way > any breaking changes (either intentional or accidental through unknown > bugs) won't impact the community. If anyone wants LINQ support, or > bulk updates, or any other feature that requires the new parser, then > they should be explicit in their configuration and make sure that they > run a full regression test of their system. That way, we don't have > to be quite so concerned about making the two parsers match > exactly. I think that there are good advantages to staying roughly in > sync with Hb, and these breaking changes are ones that they seem to > have been happy to take. > > On Apr 15, 8:53 am, Ayende Rahien <[email protected]> wrote: > > So, should it work or shouldn't it work? > > > > > > > > On Wed, Apr 15, 2009 at 9:33 AM, Fabio Maulo <[email protected]> > wrote: > > > 2009/4/15 Ayende Rahien <[email protected]> > > > > >> I would say that this should be broken then. > > >> What I would expect it to do is compare the ids, but that is okay, > since > > >> we can just user e.Reverse.id = a.Forward.id > > > > > but the default, in case of relations, is the id > > > > > -- > > > Fabio Maulo >
