On Thu, Sep 2, 2010 at 1:11 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Sep 2, 2010 at 2:04 PM, <hwright_at_apache.org> wrote:
>> Author: hwright
>> Date: Thu Sep 2 18:04:32 2010
>> New Revision: 992041
>>
>> URL: http://svn.apache.org/viewvc?rev=992041&view=rev
>> Log:
>> JavaHL: Make a couple of URI fields of the public java.net.URI type.
>
> I don't agree with this at all. I hope you do not plan to run through
> the API and make more of this.
>
> In this case, there is zero benefit to doing this and I do not have
> any confidence you have done the investigation needed to know if there
> are any detriments. Do you KNOW that this class will accept all
> possible values SVN will give it?
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."
> That said, this class only provides data from the API to the caller.
> The caller is going to prefer String. Why make them run URI.toString?
I understand that Subclipse might prefer String, but that does not
mean that all callers do. In general, I think it wisest to use the
type system, as well as the documentation, to communicate with API
users about what types of data they can expect from the API. We are
working with a language which innately supports a URI datatype (unlike
the core libraries), and I struggle to see why adding more type
information is a bad thing.
> The only place where stuff like this would make sense would be on
> Input to our API. So that users knew what they were expected to
> provide. As I said on IRC, I think it would be a mistake to do this.
> String is easier. In Subclipse we use File or URL in our API, and it
> is a pain to maintain. I wish we had just used String like JavaHL.
Per our IRC conversation, I agree that it is unwise to convert Strings
which may represent either a local path of a remote location.
However, in cases where anything other than a well-formed URI (or
null) is valid, it makes sense to use a more specific type. I've no
plans to change cases where a String could represent either a local
path or a remote URL.
> 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).
Best,
-Hyrum
Received on 2010-09-02 20:34:29 CEST