Re: [Jython-users] ProxyMaker not found?

[<bc...@wo...>]

[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