Re: [Pyobjc-dev] Re: Structs, tuples and instances

[Ronald O. <ous...@ci...>]

On 4 nov 2003, at 11:09, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> The patch for Python is easy enough, but there is one major downside 
>> of this patch: writeable structseqs are not hashable, which makes it 
>> impossible to use these objects as keys in dictionaries. Making them 
>> hashable would be easy, it would even decrease the size of the patch, 
>> but would make it possible to create invalid dicts:
>
> I'm not sure why anybody would expect things like NSPoints, NSRects
> and NSSizes to be immutable? Being tuples in PyObjC adds a feature
> which has no equivalent in ObjC, isn't it? In fact, it prevents you
> from doing even point[0] = 1 not to mention point.x = 1...

Tuples are commonly used to represent C-structs in Python. That is the 
only reason for using tuples to represent NSPoint as a tuple. As 
several people noticed,  myrect[0][1] is a lot less readable than 
myrect.location.x, which is why structseq's would be usefull.

Structseqs are backward compatible with tuples, and therefore 
immutable. I agree that immutability isn't very usefull, but it buys 
you one important feature: structseqs are useable as keys in 
dictionaries. Mutable structseqs would not be useable as dictionary 
keys, because such objects would not have a constant hash (and 
therefore should be unhashable)

Does anyone use points, rects or sizes as the key in a dictionary? If 
not, we could change the representation of NSPoint, etc., to mutable 
structseq's (with a prominent notice in the release-notes for the next 
release, as this is a backward incompatible change).

We could also add a hash function to mutable structseqs, with a note in 
the documentation that you shouldn't modify a mutable structseq object 
that is used as the key in a dictionary. None of the mutable types in 
the Python distribution seems to do this.

Ronald