RE: [Jython-dev] The future of CollectionProxy

[brian z. <bz...@zi...>]

> Hi,
> 
> With the introduction of iterators, there is no longer a 
> driving need to have a collection proxy for each PyInstance. 
> We could instead have a static collection of the (5 to 7) 
> different supported CollectionProxies, and the right 
> CollectionProxy is found whenever the __len__ and __XXXitem__ 
> methods is called.
> 

I don't understand how this is intended to work.  Would you change the
CollectionProxy's as they are now to static classes which (as you
describe below) figure out on each call what instance type the object is
and make the appropriate mapping call (ie, __finditem__(int) ->
List.get(i))?

> Pros:
> - We will save a pointer for each instance of PyInstance and
>   PyJavaInstance and an instance of a CollectionProxy for each Vector,
>   Hashtable, Map, etc.
> 
> Cons:
> - A serie of instanceof operations is necessary every time one of
>   the sequence method is called on a java instance.

I would think it would be more straight forward to keep the
CollectionProxy's as they are now even though it requires an extra
instance.  While the number of Collection classes is small it still
*feels* better to avoid a big if block of instanceof calls.

> - It would not be possible to index a java.util.Enumerations and a 
>   java.util.Iterator (but will still be possible to iterator 
> over them).

I never feel inclined to index an Iterator or Enumeration in Java, so I
don't think this limitation is very significant.

Just so I'm clear (I implemented the iteration protocol for PyCursor),
did you decide to add a new method __iternext__ to avoid having to raise
a StopIteration exception to indicate the end of the iteration?  The
spec calls for a .next() method to raise a StopIteration to indicate
stopping, so I needed to implement two methods to do roughly the same
thing, though one returns null and the other raises an exception.  It
seems to work just fine and I see that the compilation step looks for a
__iternext__ so I presume all is well.

I like the pattern of the implementation of CollectionIterX you
submitted.  I'd like to see the same done with Py.java2py so I can
finally have native proxy support for BigInteger and BigDecimal.

thanks,

brian