You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Steve Dwire <sd...@pcsigroup.com> on 2003/12/18 15:36:07 UTC
Post-1.0 TASK: Official OO Hierarchy for Bindings?
(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
Re: Post-1.0 TASK: Official OO Hierarchy for Bindings?
Posted by Ben Reser <be...@reser.org>.
On Thu, Dec 18, 2003 at 10:36:07AM -0500, 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?
Not possible to have a unified setup between all the languages. Every
language has its own peculiarities and style. For some languages
(probably the scripting languages) we're going to have to jump through a
lot of hoops in order to make the bindings work. You might be able to
come up with the least common denominator that all the languages can
support but you'll end up with something really ugly and unnatural in
the some languages.
The objectification of the Perl Client side bindings is necessary to
work around some lifetime issues where we set callbacks with variables
that perl reaps on us if we don't store them someplace. Both clako and
myself tried several tricks to work around this issue. The most recent
being the CV hack. Unfortunately, none of them work in a reliable way
for various different perl constructs (cv fails for closures but works
for everything else).
Every language is going to have issues like this (except maybe C++ which
probably can wrap things in a pretty straightforward way). If we write
up a standard for the way all the OO stuff is done it will be littered
with exceptions. I think the far better thing to do is simply let the
various binding people do their thing. They know what constructs and
layouts work best in their languages. If they document what they've
done (which I'm trying to do carefully for the perl bindings) then I
think we'll be far better off.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Post-1.0 TASK: Official OO Hierarchy for Bindings?
Posted by Ben Reser <be...@reser.org>.
On Thu, Dec 18, 2003 at 11:07:39PM +0000, Barry Scott wrote:
> 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.
The Perl bindings are swig based which means they are generated off the
C API.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Post-1.0 TASK: Official OO Hierarchy for Bindings?
Posted by Barry Scott <ba...@barrys-emacs.org>.
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
Re: Post-1.0 TASK: Official OO Hierarchy for Bindings?
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Steve,
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
>
>
Do not forget the javahl bindings,which were inspired by 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
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org