Re: [Jython-dev] importing compiled code

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> So maybe the ability to use the proxies directly from jython isn't so
> far away.
> 
> Rather than trying to decide if "z" should be a module or a class, we
> should give the user the option of choosing. Maybe as additional options
> to jythonc where the user can specify which of classes what should
> become main proxies (main proxies are real java classes, ordinary
> proxies are innerclasses). By default the module name will be importable
> as a module unless it is overridden as a main proxy. So
> 
>   jythonc z.py
> 
> would create a z.class proxy and no module, and
> 
>   jython --mainproxy="" z.py
> 
> would create a z.class module and a z$z.class proxy.
> There is probably better and more natural ways of specifing this, but I
> hope you get the general idea.

Yes, good point.
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:
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),
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. From the technical side
a more loose coupling is quite better (also in single proxie case) w.r.t. to the 
classloaders issues.
All this involves changes to runtime and jythonc, for the moment I would
prefer keep it low-prio.

Please, what are the plans for alpha1 and up to final 2.0?
From my side I should finish clarify the cache issue. And with such
a patch it should be possible to produce an experimental version
of reloading support (in form of a python module using __import__ hook).

regards, Samuele.