On 28/04/2009, at 1:12 AM, WT wrote:
Of course the tag is a container for *a*/*one* property, the tag itself, but it's not a container for multiple properties, as others had interpreted it.
In my original response suggesting bitfields, I was responding solely to the post which outlined the scheme whereby the value was used like this:
I want table 1 to have a blue background, so I set its tag to 3. I want table 2 to also have a blue background, so I set its tag to 3. I want table 1 to have red text. Switch off tag, 3 == red text. I want table 2 to have green text. Oops - tag 3 already means blue background + red text.
The solution to this is, quite reasonably if you were stuck with a single integer, to use bitfields to separate the properties so that the "oops" situation mentioned here doesn't arise. Whether it's an appropriate use of the tag field is another question entirely, since you are almost never stuck with only the tag as the only storage available. However, if you were (for some reason), then bitfields are good.
I've noticed many modern programmers are afraid of bitfields. They don't seem to understand basic operations like bitwise AND, OR, NOT and XOR. Anyone who has programmed hardware will not have such qualms, but even without that background bitfields have their place.
So while I stress this is a theoretical argument, let's be clear: A tag *could* store 32 entirely independent 1-bit properties if you wanted, or 4 x 8-bit properties etc. So stating that it's not a container for multiple properties is incorrect. It might be ill- advised, but you could do it. And that was the point I was trying to make.
--Graham _______________________________________________ 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
