On 12/19/2011 1:43 PM, James Gallagher wrote:
On Dec 16, 2011, at 5:53 PM, John Caron wrote:
On 12/16/2011 4:24 PM, Gallagher James wrote:
On Dec 16, 2011, at 3:21 PM, John Caron wrote:
For the Collection Specification, Im thinking of using this when we
start using Java 7 (which will be in version 4.4):
http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher(java.lang.String)
<http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher%28java.lang.String%29>
Comments on this decision would be welcome.
Question: Is this part of the aggregation work that you doing that
will not use ncml?
yes, at least it does not use NcML right now.
What was the reason for the non-ncml design?
NcML is seriously overloaded with functionality. I may stuff it back in
if I see how to do so cleanly.
Comment: I really like these kinds of things in Java (e.g., their
Date stuff) but for other languages they can be a pain. One way you
can simplify implementations in other languages is to specify which
parts you're actually going to use. Languages like C++ and Python
can do this stuff - there's almost always a library out there - but
it's nice to know how much users will need.
i agree. but the getPathMatcher() seems to have a clear spec, and at
least it would be a clear reference implementation if it had to be
ported. However, I need to study it closer.
What I'm thinking about is not so much that specs are not clear, but
that they cover a wide spectrum of cases while our uses are (often)
more focused. Without knowing the actual design's boundaries, it's
hard to gauge what we really need to either build or grab from the
net. I try to have little 'unused' code lurking in our server; our
(in)famous security breech was enabled by unused features of the curl
executable. While that case is not _exactly_ the same as having extra
code in a library, it does illustrate that there is a cost associated
with 'extra' code.
Yes, extra functionality would make ports harder. As I say, I need to
study it closer.
Happy Christmas/Solstice to all!
