[Zope] Java Port

[Phillip J. Eby]

At 01:44 PM 11/4/99 -0500, Barry A. Warsaw wrote:
>
>>>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>    PJE> * Reflection: Zope makes heavy use of Python internals, such
>    PJE> as function metadata
>
>Newer versions of JPython have a lot of the reflection attributes
>expected from CPython objects.  Not all of course, and I don't know
>what Zope requires, but e.g. func_code, func_globals, func_defaults
>are all readable.  Some reflection attrs that are writable in CPython
>may not be writable in JPython.  I'd be interested to know what Zope
>requires here.

Check out ZPublisher's "mapply.py" for what ZPublisher needs.  Basically,
it needs argument names in addition to the above, which if I recall from
JPython's  docs is not currently available (i.e. co_varnames).


>    PJE>  and examination of bytecodes used in
>    PJE> Python expressions.
>
>Okay, that's a tricky one :)

Yep.  The DTML "expr" logic scans Python bytecodes looking for ones which
access a variable name, then looks them up in co_varnames to get the name.
The purpose is so that names referenced in a Python expression can be
"hotwired" into a locals() dictionary when the expression is executed.
This is necessary because CPython can't deal with the locals() part of an
eval/exec being anything other than a 'pure' C dictionary object.  If
JPython doesn't have this requirement for eval/exec, a workaround may be
possible.

I think there may be other bytecode hacking done in the DTML classes done
for security purposes, but I don't recall off the top of my head.



>    PJE> * ExtensionClasses: ZPublisher and DTML are the only parts of
>    PJE> Zope that can work without ExtensionClasses (and DTML
>    PJE> performance suffers without the MultiMapping extension).
>    PJE> ExtensionClasses are C-based Python types which override
>    PJE> object behaviors in ways that Python objects cannot.
>
>It actually might not be hard to "port" or re-implement
>ExtensionClasses to JPython, esp. because you've got a real OOP
>underneath.  It might be as easy as deriving from PyObject, implement
>the behavior you want, and then exporting this into Python as a class
>that can be derived from.

I didn't say it was impossible, just that you need to deeply grok both
systems.  I'm one of (I believe) relatively few people outside DC who claim
even moderate grokking of ExtensionClasses, so that would seem to imply
that the potential number of people who could implement a port correctly
pretty small.  (Especially since I don't even have a rudimentary grokking
of how JPython's underlying shells work.)

Here are the things a JExtensionClasses would have to do, that I know of:

* Implement the __of__ hook (from what you've said, this probably isn't
excessively difficult)

* Implement the __call_method__ hook (requires __of__, plus a
"PythonMethod" helper class)

* Impliment inherited_attribute (or whatever the exact name is)

* Implement __class_init__ (called when an ExtensionClass subclass'
class/type object is first created)

* Allow hooking __getattr__ at a level above the level which is normally
allowed by Python (i.e., *before* the instance or class dictionaries are
searched)

Hmmm.  Y'know, now that I'm really thinking this through step by step...
it doesn't look quite as impossible as it first appeared.  However, my
first reaction to that thought is that it probably just means my grok of
ExtensionClasses themselves isn't as good as I think.  :)

Mainly though, it's occurring to me that a lot of the deepest voodoo I know
of in ExtensionClasses has to do with making C subclassable in C or Python,
and keeping track of reference counts.  Since JPython already makes the
underlying language subclassable, and doesn't *need* reference counts...  Hm.


>It would be a very useful discussion to have.  I'd like to see much
>more convergence in the reflection and extension areas of the two
>implementations.

The interesting bit seems to be this: if the truly hard work of
ExtensionClasses has already implicitly been done in JPython, it might make
it more reasonable for somebody with a deep JPython knowledge to worm the
necessary remaining ExtensionClass knowledge out of the DC folks or persons
like myself.

My interest in the project is rather limited, in that Java's not a buzzword
I currently need for any of my work.  But if it's doable, it'd be an
interesting curiosity.  Of course, once Zope itself is up, there are still
things like intSet and BTree that have to be converted from C, as well as
the cOptimizations, cPickleCache, etc.  Which I expect will all have
challenges of their own.  In other words, "the devil is in the details."