On Thu, Sep 2, 2010 at 2:33 PM, Hyrum K. Wright
> 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.
Received on 2010-09-02 20:43:31 CEST