• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: What is the purpose of static typing?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the purpose of static typing?


  • Subject: Re: What is the purpose of static typing?
  • From: Richard Wolf <email@hidden>
  • Date: Wed, 24 Jul 2002 23:35:45 -0500

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.
  • Follow-Ups:
    • Re: What is the purpose of static typing?
      • From: Ryan Dingman <email@hidden>
References: 
 >Re: What is the purpose of static typing? (From: Philip George <email@hidden>)

  • Prev by Date: Re: any constructor
  • Next by Date: Re: How to truncate NSStrings?
  • Previous by thread: Re: What is the purpose of static typing?
  • Next by thread: Re: What is the purpose of static typing?
  • Index(es):
    • Date
    • Thread