Iterators verses Callbacks
The STL uses iterators to traverses through containers. Why does Data Access
use callbacks? A fundamental limitation with iterators is that they can
return only datums that are well known at compile time. If a different type
is returned by the iterator then we must recompile the program. Iterators
are frequently based on templates. This allows the same iterator to be used
with many different types, but we must recompile the program to process a
new type.
In contrast, DataAccess allows different container types to be accessed
without recompiling the program to accommodate a new data container.
We could have the iterator return a reference to an interface such as a
PropertyCatalog, but in general it is preferable to return copies from
iterators instead of references. Why is that you might ask? The answer is
fundamentally tied to object lifespan issues. If an iterator returns a
reference then how long can we safely use that reverence? What if the
implementer of the iterator wanted to inflate a temporary object
implementing the interface and return a reference to it from the iterator?
How long will the client of the iterator continue to use that reference?
When can the implementor of the iterator safely destroy the copy of that
temporary object? The only safe solution would be to return a reference
counting smart pointer from the iterator. However, IMHO, the complexity of
that approach makes the use of iteartors that return references to
interfaces quite questionable from a performance perspective.
In contrast, DataAccess prefers to expose sequences of interfaces using
callbacks where the lifespan of the temporary object implementing the
interface presented is quite clearly understood to be the duration of the
callback.
Jeff
__________________________________________________________
Jeffrey O. Hill Mail JOHill@lanl.gov
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA Fax 505 665 5107