Then, I guess that if you want to be able to get the results multiple times
without actually enumerating the original enumerable you need to cache the
enumerations, so that once it's enumerated for the first time, subsequent
enumerations go to the cache. Would this make sense? We already have a
cached enumerator, this would simply mean to swap the OneTimeEnumerable with
the CachedEnumerator.
On Sat, Feb 21, 2009 at 16:19, pb648174 <goo...@webpaul.net> wrote:
>
> I just looked at the change below:
>
> if (alreadyEnumerated)
> return Enumerable.Empty<T>().GetEnumerator();
>
> Which I think will also lead to unexpected results. For example, if 3
> rows, rows.Count() will return 3 the first time and 0 the second time.
> I would expect to be able to iterate the rows each time and get the
> data but to not suddenly multiple rows in other operations based on
> how many times the rows were iterated. I think if you want to go this
> route it should either a) throw an exception that the results are
> being enumerated multiple times so these kinds of problems are found
> faster during development or b) just allow it to be enumerated
> multiple times without duplicating rows in other operations. I'm not
> sure if b) is possible without losing the benefit of yield return
> flowing through all the operations, that's why I was curious to see
> how you solved it.
>
> On Feb 21, 8:40 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> > Sure, any feedback is welcome, I'm not sure that what I choose to do is
> the
> > best solution. I simply decorated the enumerable so that it cannot be
> > iterated more than once. But if you try to do so, it simply doesn't
> return
> > anything.
> >
> >
> >
> > On Sat, Feb 21, 2009 at 15:21, pb648174 <goo...@webpaul.net> wrote:
> >
> > > Ok, that is interesting then, I'll take a look at the changeset and
> > > see how you did that.
> >
> > > On Feb 20, 12:41 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> > > > No, the fix didn't change this behavior. The
> > > SingleThreadedPipelineExecuter
> > > > is still pulling, while the multi threaded is pushing.
> >
> > > > On Fri, Feb 20, 2009 at 2:15 PM, pb648174 <goo...@webpaul.net>
> wrote:
> >
> > > > > The other strange bit of IEnumerable behavior is that if you don't
> > > > > iterate the rows passed in the Execute method to an operation, the
> > > > > previous operations won't execute. This makes sense once you think
> > > > > about how IEnumerable works, but from the context of making an
> > > > > operation that does something not involving rows (as perhaps the
> last
> > > > > operation to send an email or something) you can get some
> unexpected
> > > > > results. I made a ProcessAndIgnoreAllInput(rows) { foreach(var row
> in
> > > > > rows); } to get around this but maybe now I can get rid of it.
> >
> > > > > If you solved this problem by iterating the list no matter what and
> > > > > making a copy I think you will have also fixed the above scenario,
> > > > > just thought I would mention it.
> >
> > > > > On Feb 18, 7:30 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> > > > > > Fixed in revision 2044.
> >
> > > > > > On Mon, Feb 9, 2009 at 9:27 AM, Ayende Rahien <aye...@ayende.com
> >
> > > wrote:
> > > > > > > +1
> >
> > > > > > > On Mon, Feb 9, 2009 at 10:22 AM, Simone Busoli <
> > > > > simone.bus...@gmail.com>wrote:
> >
> > > > > > >> If everyone's ok with it I can change the single threaded
> executer
> > > to
> > > > > > >> avoid iterating the rows twice.
> >
> > > > > > >> On Thu, Feb 5, 2009 at 9:19 AM, webpaul <goo...@webpaul.net>
> > > wrote:
> >
> > > > > > >>> No, I can't see why anyone would want that behavior, it can
> lead
> > > to
> > > > > > >>> some unexpected results. If anything I would think the single
> > > > > threaded
> > > > > > >>> should be made to behave like the multi threaded one. I think
> if
> > > > > there
> > > > > > >>> was some reason for that behavior then an option defaulted to
> off
> > > > > > >>> would be best.
> >
> > > > > > >>> On Feb 4, 11:21 am, Simone Busoli <simone.bus...@gmail.com>
> > > wrote:
> > > > > > >>> > Yes, that sounds reasonable. Do you think it would be
> useful to
> > > > > enhance
> > > > > > >>> the
> > > > > > >>> > threaded pipeline executer to make it iterable multiple
> times?
> >
> > > > > > >>> > On Wed, Feb 4, 2009 at 3:39 PM, webpaul <
> goo...@webpaul.net>
> > > > > wrote:
> > > > > > >>> > > When I need to do anything like that I just
> > > > > > >>> > > first convert to a List<Row> rowList = new
> List<Row>(rows);
> > > which
> > > > > > >>> > > safely interates it once and then I don't need to worry
> about
> > > > > it.-
> > > > > > >>> Hide quoted text -
> >
> > > > > > >>> > - Show quoted text -- Hide quoted text -
> >
> > > > > > - Show quoted text -- Hide quoted text -
> >
> > > > - Show quoted text -- 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 rhino-tools-dev@googlegroups.com
To unsubscribe from this group, send email to
rhino-tools-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
