From: Peter B. <bri...@ma...> - 2001-08-09 06:01:42
|
Hello Robert, Thanks for your quick reply! You're right, --all does solve the problem I mentioned. I'm not totally happy with this solution, though, because I believe that the code I posted should work without the compiler classes and that the insistence on the presence of ProxyMaker is a bug (feature?) of jython. In particular, when compiled with --all, the resulting jar file can't be used for applets under netscape or mozilla because of security issues. Thanks again, Peter > I've got another problem with some code that works fine when interpreted > with jython but breaks down when compiled with jythonc. > > I've narrowed the problem down to the following situation. We need two > modules, say init.py and main.py. > > ---------------------------------------------------------------------- > init.py: > > import java > > cl=java.lang.Object > > ---------------------------------------------------------------------- > main.py > > import init > > class eggs(init.cl): > pass > > print eggs() > > ---------------------------------------------------------------------- > > The idea is to derive a class from another class that's determined in > a different module. [...] > |
From: <bc...@wo...> - 2001-08-09 19:02:09
|
[Peter Brinkmann] > Thanks for your quick reply! You're right, --all does solve the >problem I mentioned. I'm not totally happy with this solution, though, >because I believe that the code I posted should work without the compiler >classes and that the insistence on the presence of ProxyMaker is a bug >(feature?) of jython. Jythonc attempt to track the flow of name bindings of classes at compilation time. Usually this tracking doesn't have to perfect to be usefull in real life and so far I haven't been a need like yours. Clearly there is an limit on how effective the tracking can be. If init.py contain branching around the binding to cl, there is no way jythonc can complete the tracking and detect that init.cl is a java class. OTOH the example you showed isn't more complicated than jythonc should be able to detect that init.cl is java class. Please add bug report about it. regards, finn |
From: Peter B. <bri...@ma...> - 2001-08-09 22:27:37
|
Finn: > Jythonc attempt to track the flow of name bindings of classes at > compilation time. Usually this tracking doesn't have to perfect to be > usefull in real life and so far I haven't been a need like yours. Here's the reason why I'm interested in the kind of code I posted. I would like to create a number of classes that share the same factory (after Gang of Four: "Design Patterns") for creating certain objects. Ordinarily, one would pass a factory as a parameter when constructing an object. In this case, however, I would like to _derive_ a class from another class that's provided by the factory, so passing the factory as a parameter won't work. The solution I have in mind works like this: Create an initially empty module, call it init. The module that determines the concrete factory imports init and assigns the factory to this module as a module-global variable, say init.factory. Then the modules that use this factory import init and work with init.factory (or derive classes from init.factory.someClass). I'm not sure whether this is the best possible solution to the problem, but it is fairly simple and it works. The only drawback I see right now is that it requires compiler classes in jar files. > OTOH the example you showed isn't more complicated than jythonc should > be able to detect that init.cl is java class. Please add bug report > about it. I agree that it would be unreasonable to expect jythonc to track the class of any given variable. I do, however, think that a little more tracking would be helpful. I've managed to further condense my examples in order to illustrate the point. The following example works, even when compiled and packaged without compiler classes. ---------------------- example1.py --------------------------- import java cl=java.lang.Object class spam(cl): pass -------------------------------------------------------------- The next example does _not_ work without compiler classes. ---------------------- example2.py -------------------------- import java import init # any module, can be empty init.cl=java.lang.Object class spam(init.cl): pass -------------------------------------------------------------- It appears that jythonc does not track classes across module boundaries, even though this kind of tracking shouldn't be too difficult in this case. I think this behavior might qualify as a bug; after all, the two programs listed above are pretty much the same, so it seems reasonable to expect them to behave in the same way. Any thoughts? Best, Peter |
From: <bc...@wo...> - 2001-08-10 05:56:49
|
[Peter Brinkmann] >Here's the reason why I'm interested in the kind of code I posted. >I would like to create a number of classes that share the same >factory (after Gang of Four: "Design Patterns") for creating certain >objects. Ordinarily, one would pass a factory as a parameter when >constructing an object. In this case, however, I would like to >_derive_ a class from another class that's provided by the factory, >so passing the factory as a parameter won't work. > >The solution I have in mind works like this: Create an initially >empty module, call it init. The module that determines the concrete >factory imports init and assigns the factory to this module as >a module-global variable, say init.factory. At runtime? >Then the modules that >use this factory import init and work with init.factory (or derive >classes from init.factory.someClass). Remember that init.factory.someClass must be bound to one java class at compile time to make static subclassing work. >I'm not sure whether this is the best possible solution to the problem, >but it is fairly simple and it works. The only drawback I see right now >is that it requires compiler classes in jar files. If init.factory.someClass can change between different runs, then you need the compiler classes. >> OTOH the example you showed isn't more complicated than jythonc should >> be able to detect that init.cl is java class. Please add bug report >> about it. > >I agree that it would be unreasonable to expect jythonc to track the class >of any given variable. I do, however, think that a little more tracking >would be helpful. I've managed to further condense my examples in order >to illustrate the point. > >The following example works, even when compiled and packaged without >compiler classes. >---------------------- example1.py --------------------------- >import java > >cl=java.lang.Object > >class spam(cl): > pass >-------------------------------------------------------------- It also assumes that cl isn't changed later on. Normally the assumtion holds. >The next example does _not_ work without compiler classes. >---------------------- example2.py -------------------------- >import java >import init # any module, can be empty > >init.cl=java.lang.Object > >class spam(init.cl): > pass >-------------------------------------------------------------- > >It appears that jythonc does not track classes across module boundaries, >even though this kind of tracking shouldn't be too difficult in this case. It is beginning to look like some other module could make changes to init.cl, say bind it java.util.Date. If we improved the tracking, such a rebinding would have no effect. The java.lang.Object would always be used as superclass to spam. >I think this behavior might qualify as a bug; after all, the two programs >listed above are pretty much the same, so it seems reasonable to expect >them to behave in the same way. Any thoughts? I don't mind calling it a bug. Please add a bugreport with the all the examples you have shown. Just be sure that you know and understand the static nature of a jythonc compiled program. regards, finn |