Re: What is the purpose of static typing?
Re: What is the purpose of static typing?
- Subject: Re: What is the purpose of static typing?
- From: Ryan Dingman <email@hidden>
- Date: Thu, 25 Jul 2002 00:53:07 -0700
Hi Philip,
Richard is correct. You are very far from reality here. The _only_
time where dynamic versus static typing makes a difference is a compile
time. It makes _no_ difference at runtime. Static typing helps the
compiler check that the object in question actually responds to the
methods which are invoked on it. Your "benchmark" isn't demonstrating
what you think it is. Your use of threads is likely skewing the
results.
HTH,
ryan
On Wednesday, July 24, 2002, at 09:35 PM, Richard Wolf wrote:
On Wednesday, July 24, 2002, at 09:27 PM, Philip George wrote:
They're bound "as needed" during runtime, not at applaunch, so as
users pop open new windows (for instance) they are bound at that
moment. Once bound, it's smooth sailing, but the user does have to
wait for binding to take place that very first time that object is
used/referenced.
Okay, but if I'm reading Apple's Objective C bible correctly, methods
are always bound to objects "as needed" regardless of whether you
statically type them or not. If you statically type an object in
source, it will -still- be bound to a message at runtime "as needed"
and not initially ... when the app launches.
I just created a test app with two nswindows (programatically)
created and each has 50 nstextfields. win1 and it's 50 textfields
are all typed as "id" while WIN2 and it's 50 textfields are
statically typed.
Okay ...
after app launch i click the button, whose action method detaches the
2 threads like so:
- (IBAction)myAction:(id)sender {
[NSThread detachNewThreadSelector:@selector(winONE:) toTarget:self
withObject:nil];
[NSThread detachNewThreadSelector:@selector(winTWO:) toTarget:self
withObject:nil];
}
Notice that I give the 'id' window a head start. Even with the head
start, the 'id' window is drawn **long** after the statically typed
window and it's statically typed textfields are completely drawn to
the screen.
I don't buy your methodology ... :-)
Because you're using NSThreads, which are built on top of
pthreads/Mach, you can't have any real idea how each thread is
scheduled. I don't think it's safe to say, for example, that
"winONE's" thread is given a "head start" just because you spawn it
one line before "winTWO's" thread in your source. pthreads can
schedule the threads any way it likes and you wouldn't know. :-)
What's more, it can suspend execution of any thread at any time and
there is no way for you to accurately predict or control when it does
so.
Not that I'm saying you're wrong ... but you'll have to come up with a
better benchmark. If you are right, I'm going to re-read all the
books I have and start seriously going after non-statically typed
outlets. But my understanding, from all the newbie books, is that it
doesn't matter from a runtime perspective whether you statically or
dynamically type object pointers.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.