RE: Category or Protocol? (sidetrack)
RE: Category or Protocol? (sidetrack)
- Subject: RE: Category or Protocol? (sidetrack)
- From: Will Mason <email@hidden>
- Date: Tue, 19 Apr 2005 22:31:20 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
> > (2) I find it easier to think of the interface as the union of the
> > specifications. I need to chase back up the inheritance tree
> > for all the methods anyway (in C++ or Obj-C), so little is gained
> by
> > double-declaring methods (in child + parent).
>
> My problem with this is where an object is to be used as a delegate.
I find that a lot is gained by putting things in the interface, whether
a delegate is involved or not, as I can always know what to expect when
I look in a specific implementation because I've seen what its
interface file claims that it provides. If the interface doesn't tell
me specifically that a certain method has been overridden, then I have
to guess about which implementation file exactly has the definition
that I'm trying to find. That annoys me.
> > (3) When looking an an implementation file, it's very easy to
> > tell which are overridden methods - they don't have a matching
> entry in
> > the header file
>
> Sorry, I don't see this one at all.
>
> a. I have to look in two files, not one, to tell which entries in one
> file don't have a corresponding entry in the other.
I couldn't agree more. I would rather depend on looking at just the
interface file to determine where to look for a method's definition.
> Its possible that I think a) is a problem because I don't know about
> some
> magical key combination in XCode that flips from
> definition<->declaration -
> I think it used to be Clover-space in CodeWarrior but can't say for
> sure.
I have to reject any system that requires me to know anything about
Xcode's editor, as I only use Xcode to add and remove files from
projects and to change build settings. I edit with vim and use a
make/xcodebuild-driven system to build. I've tried to conform by using
Xcode to edit, but the lack of its ability to support vi key bindings
has made that impossible, mainly because switching back and forth
between the mouse and the keyboard just drives me nuts. We
non-Xcode-editor people do exist, and in my case it's not out of spite,
disdain or idealogy.
> > (4) While adding a redundant method declaration does not logically
> change
> > the header file, it does change it syntactically and thus require
> > recompilation of all associated implementation files.
>
> Back in the bad old days, this used to bother me. But even an eMac
> is
> plenty fast enough for my project needs, to recompile everything.
I compile projects that depend on adding overridden methods to the
headers dozens of times per day, and I'm just not bothered by it.
> Knowing when to use #import "myclass" and when to use @class myclass;
> greatly helps factoring code into bite-sized compilable chunks, in my
> experience.
I totally agree.
Will
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden