On Thu, Jul 21, 2011 at 2:10 AM, Fred Kiefer
<fredkiefer@gmx.de> wrote:
I am not interested in Python, but looked over your changes to see what functionality is missing or different in GNUstep. One thing that I noticed was that this code expects that result of a copy operation on an NSMutableArray is a mutable array, and that on GNUstep you had to use mutableCopy. If this is true we should change the GNustep behaviour and add a test case for this.
Any other interesting stuff you found while working on this?
That's probably because NS(Mutable)Array objects in Cocoa are actually NSCFArray objects (due to the toll-free bridging mechanism), which can be either mutable or immutable.
I'd be interested to know if this is true about all toll-free bridged classes. The NSCFString class in corebase inherits from NSMutableString, however, CFStringCreateCopy(), for example, is called, will create an immutable version of CFString. Only a call to CFStringCreateMutableCopy() creates a mutable version.
Stef
On 20.07.2011 19:15, David Chisnall wrote:
Hi Everyone,
Are you worried that your Objective-C code is too fast? Too readable? Too maintainable? Well now you can fix that, by adding Python!
Attached is a diff against PyObjC that allows it to build with GNUstep[1]. This allows Python to use Objective-C objects, to subclass them, and to pass Python objects to Objective-C. There are still some bugs, but please try it, play with it, and see what breaks!
With PyObjC, it's trivial to export a Python interface for scripting your Objective-C code, so you can allow Python programmers to write plugins and so forth without needing to modify your Objective-C code.
This port was funded by Inverse: http://www.inverse.ca/.
David
[1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86.
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep