Re: Why initialize the menubar without Interface Builder
Re: Why initialize the menubar without Interface Builder
- Subject: Re: Why initialize the menubar without Interface Builder
- From: Uli Kusterer <email@hidden>
- Date: Sat, 3 Nov 2007 22:06:36 +0100
Am 03.11.2007 um 20:39 schrieb Erik Buck:
The closest Jeff gets to telling us WHY is "There are a number of
reasons why you might want to build your application without a nib.
As you may know, ‘nib’ is an acronym for no inspecting bindings.
Anyone who uses version control ... can see in the diffs that nib
files are rather opaque."
I am sympathetic to the argument that development should not depend
on opaque data files. Wait a minute: .o files are opaque,
frameworks and static libraries are opaque, most xml files are
opaque or at least incomprehensible.
But those are mainly output files, which you wouldn't check into an
SCM system. The problem is not depending on opaque file formats, it is
that two people can edit a NIB at the same time, and then you'll have
to do a bunch of work to find out what each one did and consolidate
the changes. Many XML and source code files usually are usually
formatted and organized in a way that they can be diffed and merged
automatically by most version control systems.
There is a very nice tool that opens nib files and shows you their
contents. Why single out .nib files as the one non-source-code
development resource that isn't allowed to be opaque ?
It isn't, but in Cocoa, more of your app's "smarts" are in NIB files
than in e.g. Carbon (just to pick something more of you will probably
will be familiar with, I could also choose Windows resource files or
whatever). So, while usually only GUI changes like adding new controls
or moving them bore the danger of collisions, now there's a lot more
opportunity, if you have several people working on one project.
Not to mention that it's fairly easy to accidentally disconnect a
binding or connection in IB, and you can't see that you did this by
looking at a diff of the file in the commit log.
Steve Jobs once famously personally told me (OK - told everyone in
the auditorium) the following in approximately 1989: "Every line of
code is a potential bug and has a long term maintenance cost. It
doesn't matter if the line of code is machine generated or manually
generated. The initial cost to write a line is typically small
compared to the lifetime cost to maintain it, and machine generated
code is not magically bug free. The only way to reduce the cost of
software is to produce more features with fewer lines of code."
Yes, but connections and bindings are lines of code, too. It's just
that you can only view them as a graphic in IB, and no diff tool right
now can show it as such.
It seems perverse to me that anyone would invest any effort to hard
code user interfaces.
It seems perverse to me that someone would want to use NIBs in a
team of more than three developers, while you're effectively
blindfolded and can't even do a "code review" of the NIB changes
another developer did.
Having said all that, Interface Builder is not perfect or magic.
I usually prefer an easily human readable text file to a binary
file. I like plist files. I would like a tool that could output a
nice table that summarizes all of the bindings in a nib file. But I
like any data file better than the equivalent lines of code.
Well, IMHO it depends on the kind of code. One can use macros and
other things to pretty much make a source code file look like data. In
fact, in the end, code *is* data.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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