Re: weak reference support in JyNI

First, let me say that the JyNI project is fantastic work, and we generally
try to support such projects in Jython. This is even more so when they have
minimal integration requirements for Jython core; and this is letting us
actually support the C extension API!

On Fri, May 30, 2014 at 9:49 AM, Stefan Richthofer <[email protected]
> wrote:

> Alright.
> >>it would seem better if we developed a better API
> I'm not sure, whether this would result in better API, since the JyNI
> purpose is very special and opening an official gate for this
> might encourage nasty or even malicious hacks.
>

Given that it's easy to reflect on the Jython's runtime internals, much
like Python in general, and do other crazy stuff, this is not something
that should preclude this type of API.

In order words, a language that lets one say True = 0 in someone else's
namespace, but actually doesn't have this problem in practice, is going to
be fine with this sort of hook requirement.


> So it might be better to simply keep it semi-closed and use tweaky
> solutions in
> the rare cases when it is needed. That said, let me state, what API I
> would need.
>
> I would need an interface like
>
>  public interface WeakrefListener {
>   public void weakrefCreated(AbstractReference ref);
>   public void weakrefDisposed(AbstractReference ref);  (<- I would not
> need this one, but it would be a more consequent realization of this
> functionality)
> }
>
> Any PyObject implementing this interface would be notified by the _weakref
> module once it becomes a referent or stops being one.
>

Fair enough, it's a very cheap operation to check for a specific interface
(possibly no cost, depending on inlining iirc), and is similar to other
customization hooks we already have.


> However this would not yet fix the tweak neccessary to replace the
> referent by kind of a proxy (what I need to fix keep-alive relations
> with native objects). To fix even this, I would need something like
>
> public interface WeakrefDelegate {
>   PyObject getReferentProxy(PyObject referent);
> }
>
> which is even more radical. When creating a weak reference, the _weakref
> module would first check whether the referent implements
> this interface and - if true - would use the obtained proxy as referent
> rather than the original one.
>

Also reasonable.


>  Not to imagine what bad stuff this would allow for. Maybe one should
> constrain the resulting object to have the
> same class as the original or something.
> Note that I would not need WeakrefListener if WeakrefDelegate were part of
> the API, so you would not have to include both ideas.
>
> I think I will work out #1 for now - it is the closest one to my suggested
> API extension and it would be easy for me to adopt the solution
> to a potential API change one day.
>

Let's put together a bitbucket branch with these ideas in it. This beta
phase is a good time to try these ideas out; otherwise we will have to wait
to 2.7.1. Also we can still revisit the implementation details of using
GlobalRefs.references.

- Jim

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev