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
