If you are only interested in the client bindings then its more
a matter of language culture then OO design that is the key.
The client API is not that complex after the C API detail has
been hidden.
If the Perl OO Bindings and the COM end up being like the
C++ and Python then it would not be hard to ensure common
naming etc, language permitting. If Perl and COM use svncpp
as the base then this falls out almost for free.
Barry
At 18-12-2003 15:36, Steve Dwire wrote:
>(Take 4. First 3 attempts didn't show up. Sorry if this is a duplicate.)
>
>I brought up this idea a while back, and one person seemed to think it
>was a good idea, but I wanted to solicit others' ideas before adding
>this as an official task in the issue tracker.
>
>It looks like there are attempts in different binding layers to define
>an OO interface on top of the subversion API.
>
>o First, there was svn_cpp, part of RapidSVN
>o Next was the OO Python bindings, based on svn_cpp
>o Today a discussion was started about OO Perl bindings.
>o When I brought up COM, someone suggested basing the
> hierarchy on svn_cpp
>
>My question is this: Is it within the scope of the subversion product
>itself to define what an class hierarchy should look like for an OO
>binding? I'm not suggesting that it's the responsibility of the
>Subversion project to actually *implement* any of those wrappers, or
>necessarily *include* them in an official distribution (though that
>would be nice). I just believe that for consistency's sake, there ought
>to be a single, official class hierarchy and API definition for any OO
>bindings that come down the pike. The subversion team would be
>responsible for defining and documenting the classes and their
>hierarchy/properties/methods, but not necessarily for implementing them
>in any particular language.
>
>What's the collective opinion? Should we add a TASK issue (Post-1.0,
>probably) to define an official OO API structure?
>
>S_E_D
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 00:08:14 2003