On Tue, Nov 12, 2002 at 02:18:34PM -0600, cmpilato@collab.net wrote:
> Brandon Ehle <azverkan@yahoo.com> writes:
> > In the gsvn project, there are a couple of utility classes that wrap
> > the status_t and entry_t structures called Entry() and Status().
> >
> > http://svn.collab.net/repos/svn/clients/gsvn/trunk/src/gsvn_entry.py
> > http://svn.collab.net/repos/svn/clients/gsvn/trunk/src/gsvn_status.py
> >
> > Is there any plans to make similiar classes in subversion as they are
> > useful for more than just gsvn?
Similar classes can be built, yes. These would go into
bindings/swig/python/svn/wc.py. Note that I say "similar". I think the
classes can definitely be improved. I don't like get_FOO() methods,
but think that Python attributes should be used. To avoid duplicating
the data, it is possible to use Python juju:
def __getattr__(self, name):
if name == 'kind_str':
return kind2str.get(self.kind, '?')
if name == 'schedule_str':
return sched2str.get(self.schedule, '?')
func_name = 'svn_wc_entry_t_%s_get' % name
if hasattr(wc, func_name):
return getattr(wc, func_name)(self.wc_entry)
raise AttributeError(name)
There may be other bits necessary in there, but that's the idea. That
would allow somebody do do:
entry = svn.wc.Entry(real_entry)
print entry.url
> I would say that those classes are indeed useful, but certainly not
> required. I'm of two minds on the matter though. On one hand, it
> would be nice to have those admittedly nicer interfaces be the default
> ones used by the official Subversion binding layer. On the other
> hand, that means we have to go out of our way to support that
> abstraction, not just for Python but for every other SWIG-supported
> language.
Woah... each language is going to have different needs, according to
that language. For Python, attribute-based objects are "nicest". For
Perl, tied hashes might be best. For Java, the getters are probably
best. etc.
> Sussman and I were discussing this earlier today, and I think we agree
> that this abstraction should live in the subversion tree, but perhaps
> in a separate location than the core bindings.
I think something like the above ought to go into wc.py. We can do
similar for other structures. In fact, I could even generalize the
above so that each of the foo.py files could just subclass. Something
like:
class Entry(util.ClassWrapper):
type_name = 'svn_wc_entry_t'
class Status(util.ClassWrapper):
type_name = 'svn_wc_status_t'
And that would be it :-)
But before investing a lot of time there, it might be nice to look
into SWIG's "proxy" implementations ("shadow" classes might be the
term, too). If those are complete/robust enough, then we might want to
use those. But we also need to mix our own code into whatever SWIG
generates (e.g. the Editor class in delta.py).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 12 21:47:41 2002