From: <bc...@wo...> - 2000-11-21 11:53:25
|
On Mon, 20 Nov 2000 15:24:42 +0100 (MET), you wrote: >From my viewpoint the main problem we are dealing with are the name >clashes, so if we want the new feature is better to revert the old practice: Ok, I'm not in any way married to the existing default behaviour of jythonc. >user compiles a set of modules and marks through jythonc cmd-line options or >"@sig"-like docs for which classes he wants to get pre-comp proxies, >in principle he should avoid name clashes between proxies and modules, and >such clashes are errors. >But to be backward compatible if there is "just one" of such clashes, >a proxie for the involved class (e.g MyBean) is produced with the right name >and behind the scene the enclosing module is renamed (MyBean -> MyBean_home), No. Changing the module name is wrong. Changing the name without giving the users control over the new name is twice wrong. >the assumption here is actually that people with the current usage of jythonc >ignore the module at all, clearly a warning should be issued. >2nd: the fact that actually things (module and proxie) are packaged together >as inner class and class is nice, but if we can create more than a proxie >from a single py this does not work anymore. It doesn't? It works in the cases I have tried. Only the MyBean.MyBean class will become the main proxy. The other classes are usable from java as MyBean.MyOtherClass. Here is another suggestion. The default for jythonc is changed so that the MyBean.class is a module and the proxy for MyBean.MyBean is a public static innerclass. There will be two ways of changing this default: 1) A new option "--mainproxy" which will cause the MyBean$MyBean.class proxy to be renamed to MyBean.class and the module is lost. So to get the current behaviour for existing applets, the --mainproxy option must be specified. If the MyBean.MyBean class isn't a java class, a warning is issued. No warning is issued for the loss of the module, since it is done on behalf of the user. 2) Marking the class with the text "@mainproxy" in the class's doc-string. If the MyBean.MyBean class is marked this way, the module is overriden and lost. No warning is issued for the loss of the module. If other classes in MyBean is marked with "@mainproxy", jythonc will create separate MyOtherClass.java source file, one for each "@mainproxy" marked class. I think it is Ok to lose the module when it happens based on a deliberate user choice. (There haven't been a great demand for the module). Changing the default will very likely become a faq: "Why doesn't my applet work anymore", but I think we can answers these questions as they are asked. >From the technical side >a more loose coupling is quite better (also in single proxie case) w.r.t. to the >classloaders issues. Right now there is a strict coupling between the module and the proxies: the proxies accessed through the module will be loaded by the same classloaded that loaded the module. That coupling should probably be loosened in some way, I haven't looked into that. regards, finn |