Bug, compiler problem, or rift in time/space continuum

[Brad O'Hearne]

All,

I am having a compilation problem so befuddling to me that I'm
suspecting the answer must be incredibly easy -- typical cross-eyed
developer syndrome that happens when coding for very long hours.
Anyway, here's the deal:

I have an iPhone application project A, which is dependent upon static
library B. In project B, I have two classes, X and Y, which are
totally unrelated to one another, and have no references to one
another at all. However, in each class, there is an init method with a
similar signature.

In X:
- (id) initiWithDelegate:(id <XDelegate>)delegate;

In Y:
- (id):initWithDelegate:(id <YDelegate>)delegate;

Switch back to project A, where I have a class Z, which imports class
X, and implements XDelegate, but has no references whatsoever to class
Y, no imports of Y, nothing, and doesn't implement YDelegate. Here is
the thing which has me beat right now -- in class Z there is a line of
code which creates an instance of X:

X *xobject = [[X alloc] initWithDelegate:self];

When I compile project A, I get a compile warning on this line of code
which says something to the effect that "A doesn't implement
YDelegate". Huh? Check this out, I can even completely remove the init
method declaration and implementation entirely from class X and it
won't change the error message. However, if I change the interface
declaration for X to this:

- (id) initiWithMyDelegate:(id <XDelegate>)delegate;

everything compiles cleanly. There is NO relationship between X and Y,
and there's nothing Z otherwise does that has anything to do with Y. I
have checked the code over and over and tested this thing for about 2
hours now, and I don't get it -- the answer must be something simple,
but the thought that there's something about iPhone static libraries
and/or headers that prevents me from using the same method signature
across two completely unrelated classes just can't be right.

Does anyone have any insight to the problem here?

Thanks,

Brad

[Bradley S. O'Hearne]

All,

I've got a wrinkle to add -- I removed Y entirely from project B, and
my compiler error changed to a third class (call it M) which -- you
guessed it -- ALSO has the same form of that init method:

- (id)initWithDelegate:(id <MDelegate>)delegate;

compiler error "Z doesn't implement MDelegate" -- again, even though Z
has nothing to do with M. It would appear, despite how crazy this
sounds, that this method signature cannot be used more than once
anywhere in the library, regardless of whether the class in which it
resides is being referenced or not. This makes no sense to me, but the
errors appear to support that, as do the things which remove the error
(changing the method name).

So I suppose there's something C or Objective C - ish that I'm totally
missing. If anyone has any clue, please let me know, because the
thought of having no scoping of method names within a class inside a
static library has me longing for any other programming language or
alternatively a mallet to the head right now.

Thx,

Brad

[Bradley S. O'Hearne]

Changing all the init method signatures fixed everything. At this
point, because I'm 99% positive that C/C++ doesn't work this way, I'm
attributing this to an Xcode problem using static libraries. Along
with my consistent IB-related resource-finding problems since Snow
Leopard / 3.2.x came out, it has to be an IDE issue. I'm starting to
strongly suspect all is not right in Xcode 3.2 -- I have experienced
these problems on both desktop and Macbook.

If anyone has any ideas, please contact me.

Thx

Brad

[Jiva DeVoe]

At the risk of being "That guy" who, when asked a direct question of
how to do some task, explains why you really don't want to do that
task at all in the first place...

I will direct you to:

http://www.wilshipley.com/blog/2005/11/frameworks-are-teh-suck-err.html

Which explains a very nice way of organizing one's code such that you
needn't build static libraries or frameworks at all. Unless you're
making proprietary libs or frameworks for third parties to use (IOW:
Unless you are Apple) there's no reason to make libs or frameworks.

This is the way I share code in my projects, and it works very well.

If this bug occurs outside of your static library configuration, then
you have some other issue going on, because I do this all the time in
my code with no such issues.

All that said... I've never heard of an issue such as this, and would
be extremely surprised to see this as a bug. To quote "The Pragmatic
Programmer": (http://pragprog.com/the-pragmatic-programmer/extracts/
tips) "Select isn't broken."

On Oct 25, 2009, at 2:12 PM, Brad O'Hearne wrote:

>

--
Jiva DeVoe
http://www.random-ideas.net
iZen Garden - Promoting Virtual Peace and Tranquility on an iPhone
near you.

[Jiva DeVoe]

BTW, one disadvantage of this... my code repository is getting a
little fat. It's tempting to pull stuff out and put it elsewhere
because of this. I think instead I'm just going to prune old
versions. SVN doesn't suffer as much from this problem because only
the server has full history, but git does, and as of now, my iPhone
software repository is about 2.2GB.... OUCH! OTOH, I store a lot of
big stuff in there too... graphics files, even videos. I like the
fact that it's all conveniently backed up to my network server.

What's Goin Down - Network Management Tools for your iPhone.

[Bradley S. O'Hearne]

Interesting....I've been using static libs for a while now, so its not
something I'm unfamiliar with, nor do I think its particularly complex
-- but it is a bit of a nuisance in project configuration. My general
thoughts on the article are as follows:

- I get the point about the problem with actual used code, but that
just an issue of library organization for the most part, but OK, I get
that. In my case, I have some isolated chunks of code all moving
toward the grand convergence in a new static lib.

- One of the problems I'm experiencing with IB would likely be
partially resolved with this. I've discovered that subclassing any UI
components such as UIView and UIViewController (which I am) in a
static library may be wreaking havoc in IB. You actually have to drag
your header files into IB, which isn't a pain in itself, but I'm
suspecting one of my problems may have to do with IB not staying in
sync with header changes on the file system.

- The other problem I'm experiencing with IB I'm not sure -- I've been
experiencing it for a couple of months now, on both old / new projects
and multiple machines -- was introduced when Snow Leopard and
compatible Xoode were installed, and others are experiencing it and
have reported it on the iPhone dev forums. I've been back and forth
with Apple support, but they keep saying they can't reproduce the
problem, which is unfortunate, because I live with it.

- The article is actually about frameworks, which is not possible, so
you actually have to to the drag / reference thing anyway if you have
any project resources like images or NIBs in your static libs.

- I'm not sure I trust the whole situation when it comes to naming
conventions -- but it would seem that the possibility for naming
conflicts might arise quickly.

Verdict -- we'll see. Apple obviously intended use of static libs,
given that there's now an Xcode template for them, but I don't know
all that implies underneath the hood. What I do know is that I've lost
many hours on this stuff...but this raises the question....

How are you linking in third party projects like Facebook Connect?
That was the same kind of issue....

Brad

[Jiva DeVoe]

Notes inline below...

On Oct 25, 2009, at 5:31 PM, Bradley S. O'Hearne wrote:

Interesting....I've been using static libs for a while now, so its not  
something I'm unfamiliar with, nor do I think its particularly complex  
-- but it is a bit of a nuisance in project configuration. My general  
thoughts on the article are as follows:

I've been using static libs for many years as well, and generally I find them to be a huge pain.  Have you ever tried to compile an OSS project that requires a particular version of a static library and which, for whatever reason, the static library gets upgraded and is no longer compatible?  PITA.  Frameworks are more analogous to dynamic libs, which have even more problems.

- I get the point about the problem with actual used code, but that  
just an issue of library organization for the most part, but OK, I get  
that. In my case, I have some isolated chunks of code all moving  
toward the grand convergence in a new static lib.

- One of the problems I'm experiencing with IB would likely be  
partially resolved with this. I've discovered that subclassing any UI  
components such as UIView and UIViewController (which I am) in a  
static library may be wreaking havoc in IB. You actually have to drag  
your header files into IB, which isn't a pain in itself, but I'm  
suspecting one of my problems may have to do with IB not staying in  
sync with header changes on the file system.

- The other problem I'm experiencing with IB I'm not sure -- I've been  
experiencing it for a couple of months now, on both old / new projects  
and multiple machines -- was introduced when Snow Leopard and  
compatible Xoode were installed, and others are experiencing it and  
have reported it on the iPhone dev forums. I've been back and forth  
with Apple support, but they keep saying they can't reproduce the  
problem, which is unfortunate, because I live with it.

- The article is actually about frameworks, which is not possible, so  
you actually have to to the drag / reference thing anyway if you have  
any project resources like images or NIBs in your static libs.

It is, but the solution works equally well for both frameworks and static libs.

- I'm not sure I trust the whole situation when it comes to naming  
conventions -- but it would seem that the possibility for naming  
conflicts might arise quickly.

Ok, now this I have to take exception to.  Seriously?  You have naming conflicts in iPhone projects?  I mean, these are NOT large projects (or they shouldn't be).  I actually look at naming conflicts as a benefit, rather than a problem.  Why?  Because naming conflicts should be like an alert to you.  They should inform you "Hey, these two classes are similar enough in functionality that I actually thought to name them the same thing!  Maybe I should combine them and reuse them!"  This is EXACTLY what you should hope for.

I've been coding for almost 20 years now.  Longer if you count on my C= VIC 20. ;)  I despise namespaces, and have pissed off many fellow programmers with my "using namespace std;" in C++ header files.  In fact, I can really only think of one case in my entire career that I have had a naming conflict, and in that case, yes, it was for two classes that were functionally the same, one written by me, another by another coder.  The solution?  Of course to merge them and make one class.  Which is exactly what you SHOULD do.

Interestingly the more difficult problem that seems to arise more often is NOT in fact naming conflicts, but two classes with *similar* (though not exactly the same) names that do the same thing.  Again, this still calls for refactoring, but it is NOT a naming conflict.

Truthfully, this sounds like premature optimization.

Verdict -- we'll see. Apple obviously intended use of static libs,  
given that there's now an Xcode template for them, but I don't know  
all that implies underneath the hood. What I do know is that I've lost  
many hours on this stuff...but this raises the question....

Just because Apple provides functionality doesn't mean you should use it. Some notable examples that come to mind are "Code and Fix" "Distributes Objects" and so on.  Can you use it?  Certainly.  And if you are providing a third party library to someone (ala Facebook connect) then PERHAPS you should - IF you don't want consumer developers to be able to see your code.  However... 

How are you linking in third party projects like Facebook Connect?  
That was the same kind of issue....

I think... (and I may be mistaken, since I have not actually finished integrating facebook connect) that they do not use a static lib for facebook connect.  You drag and drop the actual source to your project and compile their code into your project.  Exactly what Wil suggests.  As for how I handle this in my repo... that's an interesting question.  I don't want to have the third party code in my repo, so (for now) I have a filesystem layout like this:

~/Projects/ThirdParty/Facebook

~/Projects/RandomIdeas/<MyCode>

My code repo is the <MyCode> directory.  I then reference the files in ~/Projects/ThirdParty from my projects.  It requires all my machines be set up the same, but so far, I have been able to do that.  I reserve the right to change my mind at any time. ;)

[Bradley S. O'Hearne]

JIva,

Ok, now this I have to take exception to.  Seriously?  You have naming conflicts in iPhone projects?  I mean, these are NOT large projects (or they shouldn't be).  

"A" project isn't the problem. "All" projects might be a problem down the road. Take into consideration all of our internal projects, all third party libraries, and all projects for external clients -- take further into account clients who want few if any of the Apple UI widgets in their apps, requiring you to essentially write your own API. Yeah, I think there's a potential for a naming conflict. 

In fact, I can really only think of one case in my entire career that I have had a naming conflict, and in that case, yes, it was for two classes that were functionally the same, one written by me, another by another coder.  The solution?  Of course to merge them and make one class.  Which is exactly what you SHOULD do.

You've been fortunate. I've had a different experience, and your proposed solution would not have helped. Your scenario seems suitable for a situation where you are the author of all code involved, and are the author of code from the start. But if you ever find yourself having to bring two respectable source bases into your projects where there's a naming conflict on classes that are heavily used in their respective libraries, that may be more complicated than it does at first glance. While I may not have that particular problem at this moment, I'm very leery of it happening in the future, having run into that problem before. 

Brad

[Bradley S. O'Hearne]

Update: it would appear that this is a legitimate compiler bug.

Brad