LambdaContainer misbehaviour when the source contains duplicate items

[vinesworth]

A LambdaContainer is effectively a Dictionary, keyed by the source elements:

        IEnumerable<TSource> source;
        Dictionary<TSource, LambdaOperation<TResult>> lambdas =
            new Dictionary<TSource, LambdaOperation<TResult>>();

When the source contains duplicate elements, they get merged into a single LambdaOperation, which has some undesireable consequences:

1. if one of the duplicate items gets removed from the source, the LambdaOperation is removed immediately, which is equivalent to silently removing all of the duplicate items;
2. if the duplicated item raises OnPropertyChanged, the merged LambdaOperation will retranslate the notification only once, instead of one-per-duplicate, which will mislead the group operations like Sum, etc.

At the first glance it looks like simple reference counting would suffice, but I've discovered this issue while trying to make GroupBy notifications respect the ordering. That alone, in turn, requires knowing all of the source item indices, therefore a MultiMap-like solution would fit better.

If my vision of the situation is correct, I'll try fixing it as well :)

[vinesworth]

By the way: how much do you personally value the correct ordering in OLinq? :)

[wasabii]

Hiya. Yes, I know about this merging thing. I couldn't figure out a good way to deal with it. Any fix would be great. Think it works fine on reference types, but not on value types, since their equality is different. The problem is I need to be able to actually find the key for the item in the original dictionary. And that item in the original might in fact be a value type, in which case I have no real way to distinguish it.

I don't care about ordering unless OrderBy is specified.

[wasabii]

I actually think one of the best ideas I had was to implement ValueType's differently than reference types.

[mcintyre321]

It might be worth creating a Wrapper - you can't guarantee that a
particular Type won't have overridden GetHashCode()

On 15 September 2014 01:21, Jerome Haltom [email protected] wrote:

I actually think one of the best ideas I had was to implement ValueType's
differently than reference types.

—
Reply to this email directly or view it on GitHub
#9 (comment).

[vinesworth]

@mcintyre321: Unsure if it's a real issue... In my experience, the whole WPF data binding infrastructure is so reliant on GetHashCode behaving predictably, that it seems worthless to bother. Are you aware of any examples, where it's useful to override GetHashCode in some non-coventional way?

[mcintyre321]

A fair point - but the Wrapper might let you use the same code for value
and reference types internally? Anyway, I'll stick my nose out of this
discussion!

On 15 September 2014 11:48, vinesworth [email protected] wrote:

@mcintyre321 https://github.com/mcintyre321: Unsure if it's a real
issue... In my experience, the whole WPF data binding infrastructure is so
reliant on GetHashCode behaving predictably, that it seems worthless to
bother. Are you aware of any examples, where it's useful to override
GetHashCode in some non-coventional way?

—
Reply to this email directly or view it on GitHub
#9 (comment).