• 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: Spoiled by Java IDEs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spoiled by Java IDEs


  • Subject: Re: Spoiled by Java IDEs
  • From: Chris Hanson <email@hidden>
  • Date: Fri, 18 Jul 2008 10:14:44 -0700

On Jul 18, 2008, at 9:34 AM, Jeffrey Oleander wrote:

Yes, you should at least be able to get a limited
set of constructors, destructors, and a single
group of setter/ accessor/ copier skeletons as
appropriate for the language.

Objective-C doesn't have constructors or destructors; Cocoa has designated initializers and -dealloc or -finalize methods, but those are idioms that have no direct language support. Xcode can't necessarily look at declarations in an arbitrary header (after all, it might not have source for something in a framework you're using) and determine what the designated initializer you should invoke is.


Synthesized properties, on the other hand, obviate much of the need for accessor code.

I think what he was asking for was a list from
which to choose, so that he's got the methods
right there and so it generates an appropriate
skeleton of the chosen method in his new
derived class.

Even so, there are hundreds of superclass methods, due in part to the hundreds of methods added to NSObject in the category declarations used for informal protocols -- for example, the NSTableDataSource informal protocol in <AppKit/NSTableView.h>. Are you sure you'd want a list with hundreds of methods in it?


I'd settle for a decent example in the docs of
either the currrent version of a method (where
they're not virtual) or an over-ride that actually
does something useful, so that I can have some
insight into what the class designers had in mind,
which the docs carefully avoid conveying.

As has been pointed out, many classes in Cocoa are designed for use rather than subclassing.


Also, Objective-C does not have virtual (or non-virtual) methods. It just has methods which are always dispatched to dynamically at runtime. It also doesn't have "final" or "sealed" classes like Java, Dylan or C#. Thus one can't just look at a header file and see "this class isn't intended to be subclassed" or "this method is/isn't intended to be overridden."

At least some of the commonly-requested IDE features are derived from features of the languages used in those IDEs, and as Objective-C is a different language with a different, long history of its own, an IDE for Objective-C development is going to be different than one for development in some other language.

  -- Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Spoiled by Java IDEs
      • From: Jens Ayton <email@hidden>
References: 
 >Re: Spoiled by Java IDEs (From: Jeffrey Oleander <email@hidden>)

  • Prev by Date: Re: Spoiled by Java IDEs
  • Next by Date: Re: Problem compiling first Cocoa app in Xcode 3.1
  • Previous by thread: Re: Spoiled by Java IDEs
  • Next by thread: Re: Spoiled by Java IDEs
  • Index(es):
    • Date
    • Thread