FROM : Chris Suter
DATE : Thu Mar 27 22:15:00 2008
On 28/03/2008, at 3:23 AM, Ken Thomases wrote:
> On Mar 26, 2008, at 11:43 PM, Graham Cox wrote:
>> I have a class that can contain different objects which all derive
>> from a class R. The container can accept instances of any subclass
>> of R.
>>
>> Each subclass of R implements a CLASS method for a particular
>> feature, returning an array. The container needs to build an array
>> which is the union of all the arrays returned by each subclass.
>> Thus it needs to iterate through a list of all possible subclasses
>> of R, combining the arrays as it goes. Problem is that not all
>> possible subclasses of R are known until runtime, so I need a way
>> to be able to get hold of such a list, based on the fact that they
>> all inherit from R. Note that these are not instances of R, but
>> classes. (I can get a list of instances I have right now, but that
>> doesn't cover the possibility of another object instance derived
>> from R being added after I already built the array).
>>
>> Hope this makes sense - any ideas?
>
> You seem to have solved this, but there might be a better way:
>
> Implement +initialize on class R. Reading the docs on +initialize,
> you'll find that it's called for subclasses of R, too, if those
> subclasses don't override +initialize. Even if a subclass does
> override +initialize, you can make it a part of the design contract
> that they must call [super initialize]. (Yes, that goes against a
> suggestion in the docs, but in this case you're doing it with eyes
> open for a specific purpose.)
>
> So, now you have arranged that R's +initialize is called for R and
> every one of its subclasses. In that method, you can use "self" to
> refer to the actual (sub)class being initialized and do whatever is
> appropriate from there.
The problem with using initialize is that it's only guaranteed to be
sent just before the first message is sent to that class (which might
not be at all if the class isn't used).
- Chris
DATE : Thu Mar 27 22:15:00 2008
On 28/03/2008, at 3:23 AM, Ken Thomases wrote:
> On Mar 26, 2008, at 11:43 PM, Graham Cox wrote:
>> I have a class that can contain different objects which all derive
>> from a class R. The container can accept instances of any subclass
>> of R.
>>
>> Each subclass of R implements a CLASS method for a particular
>> feature, returning an array. The container needs to build an array
>> which is the union of all the arrays returned by each subclass.
>> Thus it needs to iterate through a list of all possible subclasses
>> of R, combining the arrays as it goes. Problem is that not all
>> possible subclasses of R are known until runtime, so I need a way
>> to be able to get hold of such a list, based on the fact that they
>> all inherit from R. Note that these are not instances of R, but
>> classes. (I can get a list of instances I have right now, but that
>> doesn't cover the possibility of another object instance derived
>> from R being added after I already built the array).
>>
>> Hope this makes sense - any ideas?
>
> You seem to have solved this, but there might be a better way:
>
> Implement +initialize on class R. Reading the docs on +initialize,
> you'll find that it's called for subclasses of R, too, if those
> subclasses don't override +initialize. Even if a subclass does
> override +initialize, you can make it a part of the design contract
> that they must call [super initialize]. (Yes, that goes against a
> suggestion in the docs, but in this case you're doing it with eyes
> open for a specific purpose.)
>
> So, now you have arranged that R's +initialize is called for R and
> every one of its subclasses. In that method, you can use "self" to
> refer to the actual (sub)class being initialized and do whatever is
> appropriate from there.
The problem with using initialize is that it's only guaranteed to be
sent just before the first message is sent to that class (which might
not be at all if the class isn't used).
- Chris
| Related mails | Author | Date |
|---|---|---|
| Graham Cox | Mar 27, 03:01 | |
| Sherm Pendley | Mar 27, 03:19 | |
| Graham Cox | Mar 27, 05:01 | |
| Graham Cox | Mar 27, 05:10 | |
| Graham Cox | Mar 27, 05:43 | |
| Sherm Pendley | Mar 27, 06:01 | |
| Sherm Pendley | Mar 27, 06:11 | |
| Graham Cox | Mar 27, 06:59 | |
| Chris Suter | Mar 27, 07:59 | |
| Graham Cox | Mar 27, 10:50 | |
| Ken Thomases | Mar 27, 17:23 | |
| Chris Suter | Mar 27, 22:15 |






Cocoa mail archive

