On Tue, May 7, 2013 at 1:15 PM, Andi Vajda <va...@apache.org> wrote:
>
> On May 7, 2013, at 9:03, Barry Wark <ba...@physion.us> wrote:
>
> > Andi, thank you for the great info!
> >
> >
> > On Tue, May 7, 2013 at 11:58 AM, Andi Vajda <va...@apache.org> wrote:
> >
> >>
> >> On Tue, 7 May 2013, Barry Wark wrote:
> >>
> >> I recently discovered JCC (awesome project!) and am attempting to use it
> >>> to
> >>> wrap a Java API for Python users. It's been working great, with two
> >>> exceptions. I'd be grateful for any advice on the following:
> >>>
> >>> 1) Public methods from implemented interfaces are not wrapped
> >>>
> >>> We have where (public) methods of interfaces are not wrapped. Here's a
> toy
> >>> example:
> >>>
> >>> package us.physion.mixin;
> >>> public interface MixinA {
> >>> void mixinMethodA(String);
> >>> }
> >>>
> >>> public interface MixinB {
> >>> void mixinMethodB(String);
> >>> }
> >>>
> >>>
> >>> package us.physion.domain;
> >>> public interface Entity extends us.physion.mixin.MixinA,
> >>> us.physion.mixin.MixinB
> >>> {
> >>> void entityMethod();
> >>> }
> >>>
> >>> public interface MyClass extends Entity
> >>>
> >>> package us.physion.domain.impl;
> >>> public class EnityBase implements us.physion.domain.Entity {
> >>> }
> >>>
> >>> public class MyClass extends EntityBase implements
> >>> us.physion.domain.MyClass {
> >>> }
> >>>
> >>> MyClass is wrapped correctly, and exposes entityMethod. However, the
> >>> mixinMethodA and mixinMethodB aren't exposed. We get an AttributeError
> >>> when
> >>> calling mixinMethodA on a MyClass instance:
> >>>
> >>> In [10]: myInstance = MyClass()
> >>> In [11]: myInstance.mixinMethodA()
> >>> ------------------------------**------------------------------**
> >>> ---------------
> >>> AttributeError Traceback (most recent call
> >>> last)
> >>> <ipython-input-10-**51f1cf2e8c2d> in <module>()
> >>> ----> 1 myInstance.mixinMethodA('foo')
> >>>
> >>> AttributeError: 'MyClass' object has no attribute 'mixinMethodA'
> >>>
> >>> The issue may or may not be related to the second issue of name
> >>> collisions.
> >>
> >> You can access these mixin methods by casting to the owning interface:
> >>
> >> MixinA.cast_(myInstance).**mixinMethodA('foo')
> >>
> >> The cast_() here function rewraps your Java object with a wrapper for
> the
> >> MixinA interface (also checking that the Java instance can be cast to
> it).
> >
> >
> > Yup, that works! Is there any way to get the "uber" wrapper so that, at
> the
> > interactive prompt, a user can call any of the methods in MyClass, MixinA
> > and MixinB?
>
> I think I didn't implement that because I didn't know how conflicting
> method names would be resolved. Synchronizing multiple inheritance logic
> between Java, C++ and Python looked a little daunting.
>
Hmm, from the Java side, isn't there only one method implementation with a
given name? Java's single inheritance + interfaces (i.e. pure abstract
classes) allows only one implementation; unlike C#, there would be no way
to distinguish between different interfaces' implementations in a single
class. So would multiple inheritance really be an issue? It would make a
*huge* difference to us to be able to provide a single wrapper that exposes
all of the classes' methods, whether declared directly or by an implemented
interface.
Thanks!
Barry
>
> Andi..
>
> >
> > Thanks,
> > Barry
> >
> >
> >>
> >>
> >> Note that we have an interface us.physion.domain.MyClass, and the
> >>> implementation us.physion.domain.impl.**MyClass. JCC 2.15 sees these
> as a
> >>> name conflict, so we have
> >>>
> >>> --rename us.physion.domain.impl.**MyClass=us_physion_domain_**
> >>> impl_MyClass
> >>>
> >>> in our wrapper invocation.
> >>>
> >>> Can anyone guide me in the right direction?
> >>>
> >>> 2) Name collisions across packages
> >>>
> >>> The same example above shows a name collision
> >>> between us.physion.domain.impl.MyClass and us.physion.domain.MyClass.
> >>> We're
> >>> using
> >>>
> >>> --rename us.physion.domain.impl.**MyClass=us_physion_domain_**
> >>> impl_MyClass
> >>>
> >>> in our wrapper invocation, but --rename is not well documented on the
> JCC
> >>> web site, so i'm not positive we're using it correctly. I saw a post
> from
> >>> Aug 29 to this list that says JCC 2.16 models the entire package
> >>> structure,
> >>> avoiding these name collisions, but when running JCC from SVN trunk
> this
> >>> doesn't appear to be the case (we still get the name collision without
> the
> >>> --rename).
> >>>
> >>> Are we using --rename correctly?
> >>
> >> Looks correct to me but you should use JCC 2.16 instead and use its
> >> --use_full_names command line flag instead so that the full package
> >> hierarchy is reproduced as Python modules. JCC 2.16 is available from
> trunk
> >> and its release is imminent (PyLucene 4.3.0 rc1 is up for release vote).
> >>
> >> When using --use_full_names, you must first import your main Python
> >> extension - which causes the java packages to be installed - then the
> java
> >> hierarchy packages. For PyLucene, the main extension is called 'lucene',
> >> for example:
> >>
> >>>>> from lucene import initVM
> >>>>> from org.apache.lucene.document import Document
> >>>>> etc....
> >>
> >>>>> initVM()
> >>>>> d = Document()
> >>
> >> Andi..
> >>
> >>
> >>> Thank you,
> >>> Barry
> >>>
> >>>
>
