On Thu, 19 Oct 2000 14:19:19 +0200 (MET DST), you wrote:
>I have subscribed to the sourceforge lists and so I have received the last mail
>from Finn (twice).
>Have I missed something in between?
Not from me.
>Things seem to get clearer both for semantic and possible implementation
>up to Barry inputs.
>I clarified to myself that jythonc should build the list, use the new
>order dealing with imports but it is not necessary that it find out
>that a py pkg is also a java pkg :). The modified runtime support
>can deal with this.
I can make this change. Py.initProxy will then get a new "String
modules" argument. I'll make it a patch,, i.e I will not commit this
until we have settled the complete semantic change.
>But there is another issue: I have not yet analyzed it in depth.
>One can compile a set of py modules/py pkg under a user-defined
>java pkg (package jythonc option) so for example py mod x.y
>will be userpkg.x.y.
>If the code in interpreted mode load a java class x.JClass what should do
>at runtime the same code when compiled and put in the pkg userpkg,
>just still try to load x.JClass or userpkg.x.JClass, try both.
x.JClass IMO. The --package option to jpythonc should only be for the
generated code, not for the entire world.
>In any case something like java.lang.* should still be loaded as java.lang.*.
>Can we separate the different cases? What is the more coherent semantic that
>can be actually implemented?