Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> > Why are there _two_ relevant objects instead of just one being the
> > "master"? Without looking at the code I would have assumed it would
> > work like this:
> > a) a native ObjC object
> > b) a thin Python wrapper, only containing a ref to the ObjC objects
> 
> That might also work. I wanted NSObject to behave as much as possible 
> like a 'proper' new-style class (including __slots__), without copying 
> code from the python implementation.

Ah, I see what you mean: this approach would force you reimplement much
of the __slots__ logic for an NSObject.

If we would go this route, I would propose to drop support for __slots__
in NSObject subclasses. Its purpose is twofold:

  1) to define the set of names that can be used as attributes,
     causing typos in attr names to be caught earlier (or at all...)

  2) to save space in the object as it then doesn't need a separate
     __dict__ object; the attr refs live in the allocated object itself

I don't care much for #2, but #1 is useful. I could live without it,
though.

Hm, here's an idea (that probably only complicates things, so don't take
it too seriously ;-): could the __slots__ definition be mapped to ivars
in the native object? That would actually be pretty cool, except it
doesn't save space, since all attrs need to be wrapped in
OC_PythonObject instances... Ha, this would make the following two
classes equivalent:

  class Foo(NSObject):
      a = objc.ivar("a")
      b = objc.ivar("b")
  
  class Bar(NSObject):
      __slots__ = ("a", "b")

> It might be worthwhile to reexamine this issue after we get strings
> working properly.

Definitely not before 0.9!

Just