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 <ben@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
Received on Thu Dec 18 23:12:03 2003