[me]
> 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.
[brian]
>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))?
Yes.
>> 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 be the same two blocks of instanceof operations that you can
already find in CollectionProxy*.java. I suggest that we execute these 5
if statement for each __len__ and __XXXitem__ call on a java class,
instead of executing it just once for each java class and storing the
result. The java2 "if" statements would still be located in
CollectionProxy2.
>> - 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.
I agree; that enumeration can be indexed is IMO a sideeffect of the
implemetation. But it would be a breakage.
>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?
Yes. Maybe more importantly, to avoid having to catch StopIteration in
every loop. The StopIteration exception is used for python level code,
but the java API level uses "null" as a sentinel value.
>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.
Yes, the code you checked in is fine.
I've considered adding a PyIterator class with just:
class PyIterator extends PyObject {
public PyObject __iter__() {
return this;
}
public PyObject next() {
PyObject ret = __iternext__();
if (row == null) {
throw Py.StopIteration(null);
}
return row;
}
}
It is just a utility class that iterators can then choose to extend. It
would maybe make iterators a little bit easier to implement. Thoughts?
>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.
I think I understand what you want for BigInteger, but what should we do
for BigDecimal?
regards,
finn
|
