On Thu, Sep 2, 2010 at 2:33 PM, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote:
> After our conversation on IRC, I did write a short test program to > better investigate what the Java URI class accepted or balked at. I > discovered (empirically, so definitely not completely comprehensive) > that the URI class handles the various schemes we support just fine. > The documentation also supports this: "a URI instance is little more > than a structured string that supports the syntactic, > scheme-independent operations of comparison, normalization, > resolution, and relativization." What about performance implications? Depending how far you take this. If I were retrieving log messages, with thousands of paths, I would not want to introduce any extra clock cycles just so that SVN can convert its string into some object it thinks I might want and so that I can convert it back. Reading the JavaDoc for URI, it seems like it must do some parsing of the string so I wonder how lightweight it is. >> I think you should revert this. > > I understand your feelings. Subclipse is a very large consumer of the > JavaHL API, and the bindings have largely evolved to meet the needs of > this (very large) consumer. However, I'd like to hear what other > opinions folks may have before I make any other changes (both > reverting this change, as well as extending others in a similar vein). I do not agree with you there is any user value here. I am interested to know the full scope you intend to take this. I think people are just going to need to take the URL convert it to a String and then maybe convert the String into what they wanted (though I suspect most will want String). I do not see why we would return URI if we do not accept URI into the API. -- Thanks Mark Phippard http://markphip.blogspot.com/
