Lists and "Get"

Apr 8, 2010 at 10:39 AM

At the moment, the only "Get" method when creating lists is exposed when you have the entire collection selected

For example


                    .Impose(x => x.FirstName, "Bob")
                    .Impose(x => x.FirstName, "Alice")


All has to be called before Get is called because the SelectionCollection doesn't expose that method.

The question is, is this optimal?

We could add a Get method to the SelectionCollection, but what would it do?

It could return the current selection:


var generationContext = mSession.List<SimpleUser>();

var firstFive =  generationContext .First(5)
                    .Impose(x => x.FirstName, "Bob")

var entireCollection = generationContext.Get();

Or it could just return the entire collection

var generationContext = mSession.List<SimpleUser>();

var entireCollection =  generationContext .First(5)
                    .Impose(x => x.FirstName, "Bob")

var entireCollectionAgain = generationContext.Get();

Which of these is more intuitive (if any) - or should I just leave the Get method on the entire Collection object, and enforce that you have to call All() before Get if you're in the middle of modifying a sequence?

Apr 8, 2010 at 12:51 PM

I'd have it return the whole collection. Doing it the other way runs the risk that someone types:

var customers = mSession.List<Customer>(100).Random(5).Impose(x => x.FirstName = "Mary").Get();

They might be confused to only get 5 records.

Also, the only way to really use the interim Get() is to break up your fluent interface which now gives your users 1 API to accomplish two very different things.

P.S. I think getting interim results and manipulating them could be very useful, I just suspect that a different API might be necessary for this

Apr 8, 2010 at 12:56 PM

That's a very valid point about confusing the users - (and at the same time, I think it would be useful to have interim results!!)
Having a separate API for the lesser used one might be the right way to go

So, .Get(); Always returns the entire collection (Negating the need for All() unless you want to go back to manipulating the entire collection again)

I could add something like .Break(); to "break off" the current selection for dealing with as a whole - this could return another collection builder, only with the subset you were actively working on selected

.Break().Get(); for example

This runs the risk of people getting in a pickle when working with collections - so I'm anxious that I don't overshoot the problem and make this any more confusing than it needs to be