Re: figuring out which TableView I am?
Re: figuring out which TableView I am?
- Subject: Re: figuring out which TableView I am?
- From: Michael Ash <email@hidden>
- Date: Mon, 27 Apr 2009 00:44:10 -0400
On Sun, Apr 26, 2009 at 8:04 PM, Graham Cox <email@hidden> wrote:
>
> On 27/04/2009, at 9:31 AM, Jim Correia wrote:
>
>> 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.
>>
>> (Substitute any 2 actual properties for my background color + text
>> color - they are meant for illustration purposes only.)
>
>> Overloading tags for other properties is not scalable, because you
>> only have one property (the tag) which you are overloading to mean N
>> other properties and/or behaviors.
>
>
> This is true, but your example of non-scalability does reflect a poor
> approach that you wouldn't be likely to follow in practice.
>
> A tag is 32 bits, so can represent 2^32 different states, if used wisely.
> Dividing this into bitfields would allow you to partition it into several
> properties, for example four different colour properties, each with 256
> possible colours each.
>
> As long as you can specify your needs and know they won't need future
> scaling, you can get more out of a tag that just assigning 1, 2, 3 etc might
> suggest. The bitfield approach does have the downside of needing a bit of
> off-side calculation to arrive at the appropriate 'number' and this can be
> somewhat arcane. And yes, they are much less scalable than ivars. But it's
> definitely an approach that can be used if your needs are relatively simple.
The correct approach here is to define a property, or a set of
properties, on your table view subclass to control its appearance,
then set up those properties in your controller in awakeFromNib.
It is entirely baffling to me that people are so reluctant to follow
this approach.
The tag approach offers only one advantage: the ability to set the
value in IB. And this is an extremely limited advantage when the
information available in IB is "3". Give me descriptive code over a
"3" any day of the week.
Meanwhile it offers enormous disadvantages, including but not limited
to extremely opaque code, lack of extensibility, and just general code
smell.
Define properties for your visual differences, set them up in your
controller, and be happy.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden