[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r920363 - /subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 8 Mar 2010 10:06:03 -0600

On Mar 8, 2010, at 9:58 AM, Mark Phippard wrote:

> On Mon, Mar 8, 2010 at 10:51 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> This means we now need to keep these constructors around for backward compat, yes?
>>
>> (Even in cases where the constructor explicitly says something like "This constructor should only > be called from JNI code."?)
>
> These classes bleed into the ISVNClient interface so they are
> effectively public and ought to be usable by anyone providing an
> implementation of the interface. Another way to approach this would
> be to create additional interfaces for anything that is exposed
> directly or indirectly via ISVNClient and move all of our
> implementation classes into a package names "internal". Then we only
> need to version the interface methods and anyone that uses the
> internal implementation is on their own.

Hmm, yeah. I realize the classes are public, but I guess I always envisioned most of these as "output" parameters which should only be constructed by the internals of JavaHL. Apparently that's not a very accurate vision anymore.

The idea of using interfaces seems like the typical Java solution to this type of question, but it also seems like a lot of work. Using interfaces within interfaces does feel like the cleaner solution, though.

-Hyrum
Received on 2010-03-08 17:06:38 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.