One way to do this update in stages is to add new functions to old {quote:ClassAds} that hide the assignment operator. They would operate on the attribute name as a string and the attribute value as an {quote:ExprTree}. The internal structures could remain the same. Then, the users of the old functions could be be switched over to use the new ones. The new {quote:ClassAds} compatibility class would implement the new functions.
+{subsubsection: AttrList}
+Several parts of the code use {quote:AttrList}, which is a parent class to {quote:ClassAd} in old {quote:ClassAds}. This code can be converted to use {quote:ClassAd} instead if the put() or initFromStream() methods are used. Where those methods are used, alternative functions (which exist) need to used which don't include special handling for {quote:MyType} and {quote:TargetType}.
+
{subsubsection: ClassAdList}
There is no equivalent to the {quote:ClassAdList} class in new {quote:ClassAds}. We propose writing a compatibility {quote:ClassAdList} that's a simple wrapper around an STL vector of {quote:ClassAd} pointers. We would emulate the interface of the old {quote:ClassAdList}, but not the reference counting. Nowhere do we put the same {quote:ClassAd} into multiple {quote:ClassAdLists}.
@@ -50,7 +53,7 @@
Do we need to worry about handling exceptions from STL objects?
{subsubsection: Chained Ads}
-New {quote:ClassAds} support chaining, but the iterators ignore them. The chained ad can be referenced explicitly by callers where it matters.
+New {quote:ClassAds} support chaining, but the iterators ignore them. The chained ad can be referenced explicitly by callers where it matters. It should be possible to write custom iterators that visit the chained ad in addition to the current ad.
{subsubsection: Warnings}
It would be nice to emit warnings whereever the compatibility functions are invoked, so that we don't forget to convert them eventually.
