brian zimmer wrote:
> Randy Brown brought up that there are some issues with method signatures
> and functionality between Java and Python. For example:
>
> PyDictionary.java
> PyObject values()
>
> Map.java
> Collection values()
>
> Beyond the obvious conflict in method signatures, the requirements of
> the two values differ. In Python, the result of values() is copy of the
> contents. In Java, the result is backed by the Map. This means
> building a delegation framework is probably going to be the best
> approach to integration the Collections framework with the PySequence
> family of classes.
>
notice that in the new-style classes world, PyDictionary.values is not
going to be exposed directly through reflection anymore. So if breaking
old code relying on calling values from Java code can live with a name
change, this is not an issue.
> The following code demonstrates some of the differences.
>
> thanks,
>
> brian
>
> '''
> import os
>
> u = {1:2,3:4,5:6}
> print u
> v = u.values()
> print v
> x = v.index(2)
> del v[x]
> print v, u
>
> del u[3]
> print v, u
>
> if os.name == 'java':
> from java.util import HashMap
> u = HashMap()
> u.put(1,2)
> u.put(3,4)
> u.put(5,6)
> v = u.values()
> print v
>
> v.remove(2)
> print v, u
>
> u.remove(3)
> print v, u
> '''
>
> And for further proof:
>
> $ python
> Python 2.3 (#1, Sep 13 2003, 00:49:11)
> >>> o = {1:2}
> >>> id(o.values())
> 419888
> >>> id(o.values())
> 418896
> >>>
>
> $ jython
> Jython 2.2a0 on java1.4.2_05 (JIT: null)
> >>> from java.util import HashMap
> >>> m = HashMap()
> >>> m.put(1,2)
> >>> id(m.values())
> 1
> >>> id(m.values())
> 1
> >>>
>
> On Jan 24, 2005, at 07:21 AM, Mike Garcia (Paris) wrote:
>
>> I agree with Brian. The Collections API is the standard so it makes
>> sense to me. It will have positive impact for integration with other
>> APIs and tools as Kent pointed out.
>>
>> I've been tinkering around and discovered a few things. So far here is
>> what I've got.
>>
>> PyArray (1), PyList (2), PyString (3), PyTuple (4), PyXRange (5) all
>> depend on PySequence so; it seems to make sense that PySequence
>> implement the Collection interface IMHO. From there it appears that
>> PyList can implement List, PyDictionary can implement Map, PyTuple can
>> implement List, and PyXRange I'm not sure yet. PyString is a PySequence
>> but I don't have any ideas yet what to do with it either.
>>
>> This will probably trickle down the object hierarchy going forward for
>> example, iterators of these types will be used throughout jython
>> eventually in lieu of getting an array of PyObjects.
>>
>> Classes 1 to 5 all override the abstract protected PyObject get(int)
>> method in PySequence. I renamed this method to getPyObj (which is what
>> it really does) to facilitate List, Map etc. implementations b/c of the
>> naming issue. The impact of the change is that PackageManager,
>> ThreadState, PathPackageManager, and PyDictionary classes also have to
>> call getPyObj of the PyList class. Not a big deal I don't think.
>>
>> Any thoughts or ideas?
>>
>> Mike G.
>>
>>
>>
>> -----Original Message-----
>> From: jython-dev-admin@...
>> [mailto:jython-dev-admin@...] On Behalf Of brian
>> zimmer
>> Sent: Monday, January 24, 2005 1:26 PM
>> To: jython-dev@...
>> Subject: [Jython-dev] better Collection integration
>>
>> Dropping JDK1.1 support means we can offer better integration with the
>> Java Collections framework.
>>
>> I'd like to see the PySequence subclasses implement the corresponding
>> Collection interface. This means having a PyList instance means you
>> have a List instance. We'd also have to implement the Iterator and
>> Enumeration interfaces as well.
>>
>> The other option is to continue with the delegation pattern as done
>> with CollectionIter[2].
>>
>> I'm for the former. Thoughts? I'd like to get some of this design
>> work documented so development can begin.
>>
>> thanks,
>>
>> brian
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Jython-dev mailing list
>> Jython-dev@...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
|