Cocoa mail archive
Re: Why initialize the menubar without Interface Builder
FROM : Uli Kusterer
DATE : Sat Nov 03 22:06:36 2007
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
DATE : Sat Nov 03 22:06:36 2007
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
