Re: Java and Objective-C
Re: Java and Objective-C
- Subject: Re: Java and Objective-C
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 07 Jun 2008 14:43:26 -0700
On Jun 7, 2008, at 2:10 PM, Denis Bohm wrote:
I don't think the same level of dynamism could be added to any
other language without changing the nature of the language. For
Java, adding such degrees of dynamism would change the fundamental
nature of the virtual machines and JIT compilers in that they could
no longer eliminate call sites as a part of optimizations.
Actually, any object oriented language that has the ability to
inline methods such that they cannot be "out of lined" again at
runtime cannot support the dynamism offered by Objective-C.
Can you give a specific example of that specific point using some
Objective-C code?
Sure-- in Objective-C I can dynamically load...
[[NSBundle bundleWithPath: bundlePath] load];
... code at any time that can override or extend any class throughout
the runtime (and yes, this can be exceedingly dangerous when
overriding existing functionality).
So, consider the case where you start with this:
@interface Foo : NSObject
- (void) doSomething;
@end
@interface Bar : Foo
@end
barInstance = [[Bar alloc] init];
[barInstance doSomething];
An optimizing compiler and/or JIT might choose to inline the
invocation of -doSomething on barInstance.
Now consider what happens after I load a bundle that contains
something like this:
@implementation Bar (MySpecialGoop)
- (void) doSomething
{
....
[super doSomething];
}
@end
[barInstance doSomething];
Then a static inline or other optimization that involves bypassing the
standard messenger (objc_msgSend() for Objective-C) would fail to
invoke the newly added -doSomething.
More subtly, consider what would happen if an accessor method were
inlined by the JIT or compiler. Such an action would effectively
make it impossible to do KVO against said accessor unless the inlining
optimization could be undone.
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