Hi Darren,
Overall, the design looks really good. I have a few minor questions
about function names and "fitting in" with Python, and less minor
comments about can_handle and from_xml.
3.3: Can you clarify the reasons for the use of copy() and deepcopy()
instead of the Python standard __copy__() and __deepcopy__()?
Side-note on properties: I meant to bring this up during prototyping,
but I didn't quite get around to it. A simple attribute does not need to
be defined as a property initially, but can simply be an attribute until
a later point in time when the property concept is needed. As such, does
"name" need to be a property?
3.4.1.2: I'm not sure there's necessarily a need for both an "insert
before" and an "insert after" method. One should be sufficient?
Comparing this to 'simple' lists in Python, for example - most simply
have an "append()" and "insert()" method.
copying - Can you clarify what you mean by the "parent will be cleared"?
It sounds as if the copy()/deepcopy() methods are more akin to a "move"
operation.
3.4.1.3
to_xml: What's the reasoning behind not having the object itself make
the recursive call into to_xml()? In particular, the restriction it
creates - "it is possible... for the to_xml() method to generate the
complete tree... In this case the child objects' to_xml() methods must
return None" - seems very unintuitive.
can_handle: I can imagine that the evaluation process this would require
could get rather lengthy. There's also concern about
complexity/confusion down the line given that can_handle() could be
evaluating more than simply a high level tag. Would restraining it to
simply the top level tag and its attributes could ensure uniqueness? If
so, that could at least simplify things slightly. At minimum, I think
this setup might require some concept of ordering amongst classes, such
that if two classes happen to non-uniquely decide upon ownership of a
certain node, we can still get a consistent result back.
from_xml:
Nits on the pseudo-code: 4th line in should be "from_xml"
static vs dynamic: I believe the best solution would be a static
situation, and then simply require that any caller into this function be
sure to register all needed classes prior to calling from_xml(). For
example, ManifestParser could read in an XML, recognize that the schema
is for an AI schema, import all necessary AI related classes, then load
the DOC from the XML DOM. The import of the classes could easily be
set-up to trigger registration with the cache, as was hinted at in this
section.
3.4.2.4:
dump: Would the __str__ or __repr__ functions provide sufficient
functionality here? Or does the indented parameter imply otherwise?
3.4.3.1
1/2: Since NameValue is simply a single dictionary entry, what is the
value-added of the NameValue class?
Thanks,
Keith
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
