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

[Bob I. <bo...@re...>]

On Nov 4, 2003, at 5:45 AM, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> I agree that immutability isn't very usefull, but it buys you one
>> important feature: structseqs are useable as keys in dictionaries.
>
> How much is that worth when dealing with elements which actually
> *are* and *should be* mutable?
>
>> Does anyone use points, rects or sizes as the key in a dictionary?
>
> My point of view is that doing this is a *bad idea* and the fact
> that you can do it now introduces a source of confusion because
> it advocates usage patterns in PyObjC which are not just some
> kind of a more Pythonic way of doing something, but introduce
> artificial and unnecessary differences between PyObjC and ObjC
> on a conceptual level, which must be something to minimize if
> technically possible.

I'm with Dinu on this.  Although most of the structs passed around in 
ObjC seem to be passed by value and not by reference.. I'd still say 
that they're all mutable.  If they want something immutable they can do 
tuple(structSeqObj) or some other kind of copy.  I've never seen 
NSPoint, NSRect, etc. used as a dictionary key from PyObjC... in 
Objective C you can't even (directly) put them in any kind of 
collection b/c they are plain 'ol C structs so I don't see where anyone 
would get the idea to do it in Python.

Personally, I'd like to see how these structseq's work out (anxiously 
waiting for a commit from Ronald!).  Sounds like it might even be 
possible to use a more generic implementation as a general (and higher 
perforamance?) replacement for the struct module, at least when you're 
working in machine endian.  For example, it would be a lot more elegant 
to use structseq to read mach-o headers, and try and rig the PyObjC 
generator scripts to autogenerate structseq definitions for me.. right 
now the mach-o structures are coded by hand by looking at structures in 
C header files as a reference and I am using a module I wrote called 
ptypes which does something similar (interface wise) to ctypes 
structures and base types, but ends up having to use the Python struct 
module to do the actual en/decoding (which is kinda wasteful and 
awkward).

-bob