Phillip J. Eby wrote:
I would imagine that if we were using Python to create items in the
first place, the evolutionary pressure would've been towards providing
simpler constructors or utility functions as part of the CPIA API,
because those could be done by just writing new methods or functions,
not by needing to change an XML format.
now we're getting somewhere. I'd like to hear some suggestions about how
this could be done though. I mean is there a smarter way to use
.update() by fixing up the constructors? I thought .update() worked by
constructing the object, and then assigning attributes - but maybe what
you're saying is the arguments to .update() go directly to the
constructor? If that's the case then yeah, this does get a little
simpler.... but honestly, I'm still skeptical.
The things that are rubbing me the wrong way with .update() and CPIA are:
1) childrenBlocks & hierarchy - I want a system where the hierarchy is
implied
1a) A "nice to have" would be making the repository child relationship
match the childrenBlocks hierarchy - this is extraordinarily painful
with python at the moment and requires lots of temporaries.
2) itsName vs. blockName - I should not have to declare them seperately.
3) anonymous block names/itsname/etc - for instance menu separators
don't need itsName but .update() requires them to be consistently
findable with the same name.
4) Having to repeatedly pass in 'parcel' as the first parameter of every
single update() call.
You can fix ALL of these problems with a declarative syntax and a
processor for that syntax.
(2) could be solved by CPIA eliminating blockName and falling back to
the repository name - but I think we'd have to stop copying blocks to
//userdata to solve that problem.
An alternative that I was debating was some sort of big hierarchical
list/dict system directly in python like:
[Menu, { blockName='FileMenu', title=_('File') },
[NewMenu, { blockName='NewMenu', title=_('New...'), ...},
[MenuItem, {blockName="NewMessageItem", ..}],
[MenuItem, {blockName="NewNoteItem", ...}]
]
]
But this is basically xml-translated-into-lists-and-dicts and seemed a
little silly - I mean when writing it its harder to figure out the
correct syntax, brace balancing, and so forth.. furthermore you'd STILL
have to write some sort of processor for this datastructure. Since there
are tools to do this for you with XML (emacs, eclipse, you name it) it
just makes more sense to me to do this in XML
If you have another specific suggestion for improving cpia's API to make
this cleaner, I'm all ears.
Alec
In other words, I'm suggesting that the verbosity of defining blocks
in Python comes from CPIA-defined features, not from Python. The
simplest way to improve this would be to enhance the CPIA API -- and
not to define another data format. (Which doesn't make anything you
still have to do in Python any easier.)
Also, certain features of CPIA (such as blockName vs. itsName) might
be able to go away if we're not copying items -- or the constructors
might be changed to set blockName=itsName. There are lots of
possibilities for simplifying object creation and reducing redundancy
that are available in Python, as Bryan has also pointed out.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
