Thanks for explaining problem with instances. I came with a solution that doesn't break caller and controls instances of iterator inside the provider class. Scenario I have assumes caller knows two things - when it starts session and when it wants next item so few ways from here, other keep iterator inside caller (breaks implementation little bit) or cache it locally unless reset on purpose which doesn't break current caller implementations (demonstrated below). Other way is to wrap internal enumerator using the decorator pattern (below below)...
private IEnumerator<string> m_iterator;
public string Iterator
{
get
{
if (this.m_iterator == null)
{
this.ResetIterator();
}
return this.m_iterator.MoveNext();
}
}
public void ResetIterator()
{
this.m_iterator = this.m_internalIterator();
}
private IEnumerator<string> m_internalIterator()
{
for (int i = 0; i < m_list.Count; i++)
{
yield return m_list[i];
}
yield break;
}
Via decorator pattern, given my Provider type implements IEnumerator:
private IEnumerator<string> m_iterator;
public bool MoveNext()
{
if (this.m_iterator == null)
{
this.ResetIterator();
}
return this.m_iterator.MoveNext();
}
public string Current
{
get
{
if (this.m_iterator == null)
{
this.Reset();
}
return this.m_iterator.Current;
}
}
public void Reset()
{
this.m_iterator = this.m_internalIterator();
}
private IEnumerator<string> m_internalIterator()
{
for (int i = 0; i < m_list.Count; i++)
{
yield return m_list[i];
}
yield break;
}