Skip navigation.
 
mlRe: Objective-C and it's future
FROM : Andrew Satori
DATE : Mon Jul 10 16:43:55 2006

Not to pick nits, but this isn't an issue with Objective C, it's a 
design choice in the Cocoa class library, and it it really bothers 
you, use Objective C++ and implement an STL Vector or STL List, but I 
don't feel that it's really an issue.


No, Cocoa doesn't support what you want with the base class, but 
nothing prevents you from deriving a class that is Type specific.  I 
don't know how many people on this list have used Borland's Delphi, 
but this is literally how it deals with this situation.

There is a base class, (TList in Delphi, NSMutableArray in Cocoa) 
that is a generic array.  I deals with pointers to memory and that's 
it, so that it can take any type of item.  That leaves you, the 
developer with two options.  First, you can just use the list and 
typecast (if you desire) the array elements as you push/pop to/from 
the array.  Second, you take the Delphi type approach and implement 
type specific lists derived from the base generic list. (TStringList, 
TMenuItemList, TListViewItems, TControls, etc).  Subclass 
NSMutableArray and then embed your type casting logic into overridden 
methods.  Now the compiler will do your type checking for you.

What's interesting is that what your note appears to be asking, is 
for C# style Generics (not necessary in Objective C IMO), and C++ 
style strong typing at the same time.  The funny thing is, that 
Objective C supports variants of both and has for a long time.  The 
'id' type is little more than a 'void *' in C/C++, and due to the 
message based designs of Objective C, doesn't require all the 
internal gyrations of C#'s reflection.emit in order to accomplish the 
same basic things.  At the same time, you can be anal, like I am, and 
strong type your code.  This way I can leverage both worlds, I don't 
use 'id' very often, because I find comfort in compile time type 
checking, but it really isn't necessary, which is, in many ways the 
elegance of Objective C.

Andy


On Jul 7, 2006, at 8:42 PM, Thomas Davie wrote:

>
> On 8 Jul 2006, at 01:41, Shawn Erickson wrote:
>

>> On 7/7/06, Rob Ross <<email_removed>> wrote:
>>

>>> I'm just learning Obj-C myself, so maybe my understanding is not
>>> correct. But, don't you actually have the option to use static 
>>> typing
>>> in certain instances, and use dynamic typing in others?
>>>
>>> Eg:
>>>
>>> id      myStr;
>>>
>>> vs
>>>
>>> NSString *myStr;
>>>
>>> Won't the second version give you the benefits of static typing
>>> (compiler time checking)?
>>>
>>> So my understanding is you can have the best of both worlds. Or have
>>> I misunderstood something?

>>
>> Correct.

>
> That is correct, but can you specify for me an NSArray containing 
> only items that respond to a specific display method?
>
> This is the sort of check that I would like to be able to do at 
> compile time.
>
> Bob
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>

Related mailsAuthorDate
mlObjective-C and it's future Thomas Davie Jul 8, 01:33
mlRe: Objective-C and it's future Finlay Dobbie Jul 8, 01:46
mlRe: Objective-C and it's future Shawn Erickson Jul 8, 01:48
mlRe: Objective-C and it's future Charlton Wilbur Jul 8, 01:55
mlRe: Objective-C and it's future Thomas Davie Jul 8, 02:10
mlRe: Objective-C and it's future Robert Walker Jul 8, 02:12
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 02:22
mlRe: Objective-C and it's future Rob Ross Jul 8, 02:29
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 02:41
mlRe: Objective-C and it's future Thomas Davie Jul 8, 02:42
mlRe: Objective-C and it's future Erik Buck Jul 8, 02:50
mlRe: Objective-C and it's future Kenny Leung Jul 8, 02:57
mlRe: Objective-C and it's future Gregory Weston Jul 8, 03:00
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:00
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:00
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:07
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:12
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:14
mlRe: Objective-C and it's future Rob Ross Jul 8, 03:15
mlRe: Objective-C and it's future Rob Ross Jul 8, 03:18
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:23
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:25
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:28
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:40
mlRe: Objective-C and it's future Sherm Pendley Jul 8, 03:54
mlRe: Objective-C and it's future Kenny Leung Jul 8, 03:56
mlRe: Objective-C and it's future Shawn Erickson Jul 8, 04:22
ml[Moderator] Re: Objective-C and it's future cocoa-dev-admins Jul 8, 04:56
mlRe: Objective-C and it's future Thomas Davie Jul 8, 13:10
mlRe: Objective-C and it's future listposter Jul 8, 17:02
mlRe: Objective-C and it's future cocoa-dev-admins Jul 8, 17:05
mlRe: Objective-C and it's future John C. Randolph Jul 8, 18:50
mlRe: Objective-C and it's future Ryan Stevens Jul 8, 19:13
mlRe: Objective-C and it's future Scott Thompson Jul 10, 16:21
mlRe: Objective-C and it's future Andrew Satori Jul 10, 16:43
ml[Modertator] Re: Objective-C and it's future cocoa-dev-admins Jul 10, 17:13