Ok, mission accomplished then - Makes sense once you think about it. I certainly don't have any burning need for it to work and the easy work around is to cast one of the items as they are read in if it becomes an issue so I think it's fine. Just wanted to check if that was a desired thing or not.
On Feb 21, 10:43 am, Simone Busoli <[email protected]> wrote: > That was to point out the subtlety in the .net fx. I already discussed it, > please lookup "row equality" on the mailing list. I think this can be > addressed in several ways, but didn't take the time to do it yet. > > > > On Sat, Feb 21, 2009 at 17:13, webpaul <[email protected]> wrote: > > > I looked at some recent changes and one of them was for checking row > > equality. I noticed there was a specific test for an (int)1 not being > > equal to a (byte)1 - is that the desired behavior or was the test put > > in there just to demonstrate that subtlety? I did a little test and > > was surprised to find the below .NET framework behavior, I would have > > thought they would be equal: > > > object a = (int)1; > > object b = (byte)1; > > > Assert.IsFalse(a.Equals(b)); > > > I'm guessing the framework just returns false if the types are > > different in the Equals implementation. > > > So I understand why the test behaves how it does, just curious if that > > is the desired effect or just due to the above and you wanted it to be > > clear.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
