*: ExprTree::Evaluate()
*: Examine the resulting Value object
-This work can probably be done mostly by a student.
+This work can probably be done mostly by a student. We can also write compatibility versions of Parse() and EvalTree().
+
+In new {quote:ClassAds}, there is no assignment operator inside an {quote:ExprTree}. A {quote:ClassAd} contains a list of attribute name and {quote:ExprTree} pairs. Any code in Condor that's directly inserting or extracting {quote:ExprTree}'s from a {quote:ClassAd} will need to be updated.
{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}.
@@ -46,3 +48,6 @@
{subsubsection: String Escaping}
String escaping is different between new and old {quote:ClassAds}.
With a couple minor tweaks, the compatibility functions will use the old {quote:ClassAd} escaping rules. The new parser would continue to use the new escaping rules. We'll have to be careful when changing existing code to call the new methods, especially when parsing expressions taken from a user.
+
+{subsubsection: String Classes}
+New {quote:ClassAds} use std::string while old {quote:ClassAds} use {quote:MyString}. The compatibility functions can accept MyString where appropriate. But as new code is written or old code is converted, they will have to start using std::string.
