Re: NObjective. Fast .NET <==> objc bridge
Re: NObjective. Fast .NET <==> objc bridge
- Subject: Re: NObjective. Fast .NET <==> objc bridge
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 08 Nov 2008 21:21:22 -0800
On Nov 7, 2008, at 10:32 PM, Евгений Гришуль wrote:
Recently I started project called NObjective which main goal is create
high-performance and flexible library with low memory/cpu overheads
which
provides ability to bridge runtimes in efficient ways. Currently it
supports
codegeneration so hundreds of objc classes can be easily exported
to .NET
runtime via transparent proxies. Also you can export your own .NET
classes
to objc runtime. See timing and make right choise:
Neat. But it seems like coming out and going straight for performance
is putting the cart before the horse. Performance is entirely
secondary to the rather large challenge of making it work with minimal
impedance mismatch.
Namely, the challenge in bridging is to minimize the impedance match
between the two runtime environments. Just about every runtime
environment has its own notion of scalar types (int, float, double,
boolean, etc), string encapsulation (unicode? raw buffer? cstr only?
mutable? immutable?), array/list/vector, dictionary/hash/map, dates
(oh... the dates... how the dates hurts us), etc...
As well, there are a slew of issues on top of this.
- What happens if an exception is thrown in C#? Can it be caught in
ObjC? Vice-versa? Will it be of a sensible type?
- Strings? Don't even start with the encoding issues -- huge rat
hole. If a string is passed from one runtime to the other and back,
is the identity preserved?
- Collections -- do they "just work" on both sides of the bridge?
I.e. can you pass an NSArray instance into the C# runtime and have it
be transparently compatible with whatever vector/array thingamabob
exists therein?
- Do the fundamentals of Cocoa work? KVC? KVO? Bindings? Can I slap
an array of C# objects behind a Cocoa UI using controllers and bindings?
- How about memory management? I have seen naive bridges where every
bridge object creates a retain cycle to itself. Obviously, an extreme
fail. How much does the developer need to think about it? Ideally,
the bridge would use the garbage collector provided with Leopard.
- What about messaging? Does the bridge provide access to all Cocoa
methods? How does it deal with things like (NSError **)? How about
the various random C APIs? Or paired arguments like (int *) + count?
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden