4 ms·

Not any of those points is justified, "a nightmare", "the worst". You need to provide something to support all those affirmations.

ianstallings 13y ago
It's called an opinion. This isn't a peer reviewed paper we're talking about. And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Hardly.
- coldtea 13y ago
  >It's called an opinion. Which are like noses. Everybody has one. >And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Does he needs to elaborate more in order to justify it? Of course.
  - ianstallings 13y ago
    Well allow me to elaborate - have you ever merged two nib files? With today's variant you merge XML. With yesterday's variant you simply don't do it because it's not possible. So you're merging an obtuse XML file at best. In my mind that's painful versus merging clean .h and .m files where we know what's going on. So he's using colorful language to describe such situations - A "nightmare".
coherentpony 13y ago
Try merging a .nib. You'll see first-hand how hard it is.
- coldtea 13y ago
  Why merge it? Merging isn't even funny with regular code. How about having a process for who works on what or when? Either than or let a single person be responsible for the UI.
  - mh- 13y ago
    these things work well-enough in very small development teams.
  - cmeranda 13y ago
    We're a two person development team who sits in the same 5 foot radius and we've had to merge xibs semi-frequently. It's not overly viable to ask the person next to you what files they plan to work on in the hour, because that can be difficult to determine in advance. Additionally once I upgraded Xcode before my partner, and suddenly our xibs were out of sync. In terms of one person working on the UI, even if that's the case, the other person might change an outlet, or create a non-UI object in the xib. It's complicated to coordinate changes because the breadth of features (as they appear in the codebase) is unpredictable.

ianstallings 13y ago

It's called an opinion. This isn't a peer reviewed paper we're talking about. And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Hardly.

coldtea 13y ago
>It's called an opinion. Which are like noses. Everybody has one. >And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Does he needs to elaborate more in order to justify it? Of course.
- ianstallings 13y ago
  Well allow me to elaborate - have you ever merged two nib files? With today's variant you merge XML. With yesterday's variant you simply don't do it because it's not possible. So you're merging an obtuse XML file at best. In my mind that's painful versus merging clean .h and .m files where we know what's going on. So he's using colorful language to describe such situations - A "nightmare".

coherentpony 13y ago

Try merging a .nib. You'll see first-hand how hard it is.

coldtea 13y ago
Why merge it? Merging isn't even funny with regular code. How about having a process for who works on what or when? Either than or let a single person be responsible for the UI.
- mh- 13y ago
  these things work well-enough in very small development teams.
- cmeranda 13y ago
  We're a two person development team who sits in the same 5 foot radius and we've had to merge xibs semi-frequently. It's not overly viable to ask the person next to you what files they plan to work on in the hour, because that can be difficult to determine in advance. Additionally once I upgraded Xcode before my partner, and suddenly our xibs were out of sync. In terms of one person working on the UI, even if that's the case, the other person might change an outlet, or create a non-UI object in the xib. It's complicated to coordinate changes because the breadth of features (as they appear in the codebase) is unpredictable.