[Kde-java] QtJava rewritten as a SMOKE adaptor?

Gert-Jan van der Heiden g.j.vanderheiden at genimen.com
Mon Aug 11 14:31:41 CEST 2003


> The 'proxy' instance variables will need to be created in the constructors.
> Every Qt class like QApplication.java will need to have a corresponding
> interface QApplicationInterface.java so that all the methods the proxy
> expects to handle can be given via an array of these interface classes (for
> the current class and its parents).
>
> QApplicationInterface proxy;
> ...
>
> proxy = (QApplicationInterface) Proxy.newProxyInstance(
> 						QApplication.class.getClassLoader(),
> 						new Class[] { QApplicationInterface.class },
> 						new QtProxy() );
>
> I don't know if this makes sense, but I thought it would be a good idea to
> at least start discussing what to do about QtJava/Koala for KDE 3.2.

Hmm, I've taken a closer look at the Proxy stuff, and it raises some questions 
by me:
A proxy instance in the subject class (QApplication). That doen't make sense 
to me, but maybe I'm missing something. Normally the proxy has an instance 
handle of the subject, used for delegation.

In order to intercept calls in the Proxy, the API user should talk to 
QApplicationInterface, created by java.lang.reflect.Proxy (as you 
described above). This could be done by adding a getInstance() method:

class QApplication {
        ...
	public static QApplicationInterface getInstance(){...}
        ...
}

But that doesn't program nice:
QApplicationInterface application  = QApplication.getInstace();
instead of:
QApplication application = new Application();







More information about the Kde-java mailing list