On Apr 27, 2009, at 1:19 PM, Jonathan Hess wrote:
That cleared things up and sounds much more reasonable.
Did I sound less reasonable before? I surely hope not. :)
To take this a step further, if you're going to take the time to define constants like kTable1Tag, and then use them in IB, why not just use an outlet instead? It takes the same amount of typing, but is much more difficult to inadvertently break while at the same time, self document.
I think that's a matter of perspective and, possibly, also of personal taste. There are always cases where one solution is better than others, given a suitable definition of "better."
If you really want to identify an object by its identity there's no better way than a pointer, and that's what you get with an outlet.
Sure, but it was my impression from the OP's question that he didn't have explicit pointer variables representing his NSTableView subclass instances, or else he wouldn't have asked the question in the first place because pointer comparison is the absolute obvious solution. I trusted that the OP was knowledgeable enough to have thought of that.
Tags certainly have their place. An example of where they can be used successfully and clearly is to hold integer constant values for menu items in a pop up button's menu where the pop up menu is used to manipulate an attribute, and the menu items' tags hold the legal values.
Yes, and identifying cells in a NSMatrix by their position in the grid is probably another good example.
Look, I'm not trying to sell the tags solution as the best solution or the correct solution or the only solution or the standard solution. It's just a simple solution to a simple problem.
It baffled *me* that people (a) misunderstood the OP question, (b) misunderstood my tags solution, (c) went overboard with the whole tags- as-bitfields idea, and (d) made such a big deal about such a simple solution to a simple problem.
In the end, though, it doesn't really matter because the OP seems to be happy with the tags solution. It even looks like he completely ignored the ensuing discussion.
Wagner _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
