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

Re: JavaHL bindings cleanup

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-03-16 16:56:26 CET

Mark Phippard wrote:
> On 3/16/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> I've been mucking around in the JavaHL bindings the past few days, and I
>> have the following suggestions:
>> 1) Update the .cpp and .java files to use the same coding style that the
>> main codebase uses.
> I am not sure it makes sense to force the .java files to follow a style
> used
> in C/C++, but to be honest I am not familiar with the scope of what that
> would mean. Maybe not much. For me, since I use tools like Eclipse, I
> would just want the style to be something reasonable that I can set in
> Eclipse and let it handle for me.

That's understandable. The .java code is different enough from the .cpp
code that it shouldn't matter too much. The problem I'm trying to solve
is two-fold: the .cpp files have a style all their own, and it isn't
consistent; and, C++ is similar enough to C that when working in them,
it would be easier if they just had the same style.

Would moving function parameters to individual lines be incongruent with
prevailing Java styles?

> 2) Rearrange methods within classes in alphabetical order, with older
>> methods first in the case of overloaded methods.
>> 3) Implement older APIs as wrappers around newer APIs in the same class.
>> (Currently, some are implemented as wrappers around newer APIs in
>> other classes.)
>> I think this would improve maintainability substantially, but I wanted
>> to know what others thought. Comments? Objections?
> In general I am fine with the concept. I do not know what #3 means at a
> technical level so cannot comment. Obviously the main issue is that the
> changes do not make it too hard to backport future fixes, but I would say
> that the number of those are likely to be a number approaching zero. So
> better to do this now, well in advance of a 1.5 branch.

Other than giving the compiler/optimizer a bit more information, #3,
doesn't have much technical impact. This is mainly limited to the
SVNClientSynchronized class, which can implement old APIs using newer
ones in the same class, or by calling the new API in SVNClient. It just
seems Right to use the API in the same class whenever it is available.


Received on Fri Mar 16 16:56:42 2007

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.