Re: [Jython-dev] importing compiled code & cache...

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

Hi.

The reversed class -> module, inner class -> proxie approach is very nice
but I see the following problems:

1) with inner classes we have hard coupling => potential unwanted memory 
leakage.
2)
[Finn]
>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.
The name clash issue technically is not only related to the ambiguity of
import MyBean, the code for the module will still be needed in some form,
e.g. the proxy constructor need to load it and this create an entry in 
sys.modules and here we encounter a second name clash if the proxy
is imported in jython.
The entry will avoid multiple load and be a meet-point for the proxies
from a single module, needed if we want to share global variables and avoid
replicas of the same module.
The choices for this case:
a) a module can have only one mainproxy, this loads the module
  anonymously and cache it in a static var. (too much coupling)
b) there could be many mainproxies but:
  * we reserve sys.modules somehow only for modules (code breakage?)
  * we build another cache for modules loaded through proxies
    (personnally I don't like having more caches around, what kind of
     key to use?)
  * given the module is lost, we rename the module, and issue
    a *warning* at compile time, we give the user an option to *choose* the
    name. We take care of this by mutual loading by the whole compilation.
  * having a name clash is an error. point.
or) we setup things in the following way, given this is just to support
the actual practice (by now we cannot load compiled modules nor proxies
effectively): we revert in this case (only in this case) to your first idea:
if MyBean is the mainproxy from MyBean.MyBean => import MyBean actually
imports the module MyBean, and that's what the proxie constructor need. But I 
imagine that users want to compile MyBean to a proxy MyBean and get the proxy 
with import MyBean.
or) import detects name clashes and raise an appropriate exception.


I would like to start coding the cache/MakeProxie fixes. Please, I would
like to read your words on that?

regards, Samuele.