Re: (id) issue, passing different types during initWith:(id)type
Re: (id) issue, passing different types during initWith:(id)type
- Subject: Re: (id) issue, passing different types during initWith:(id)type
- From: Travis Kirton <email@hidden>
- Date: Sat, 29 Jan 2011 20:20:45 +0100
Q,
Ah, yes... The apocalypse was a slip... Wrote the function quite quickly.
Thanks for the advice.
As for my project, the main reason I chose to use (id) instead of anything else is that I am trying to build a set of frameworks that are "somewhat" redundant, for beginners learning cocoa/obj-c.
In particular, my project is geared towards artists who've never programmed before. I would like to build a system that allows them a bit of flexibility by hiding some of the stricter details of programming with Objective-C.
Actually, my intention with CFAString is what you list in option 3, except it might wraps NSString, CFString, etc..., so that at the end of the day the user can simply work with one object for manipulating and drawing strings.
Cheers,
T
On 2011-01-29, at 8:10 PM, Quincey Morris wrote:
> On Jan 29, 2011, at 07:29, Travis Kirton wrote:
>
>> -(id)initWithString:(id)aString {
>> if(![super init]) {
>> return nil;
>> }
>
> No, no, wrong, run for cover, incoming apocalypse. Always 'if (!(self=[super init])) ...'.
>
> Also, I can't help offering the opinion that using '(id)' for a polymorphous parameter often *looks like* the simplest choice, but often costs more source code, and defers error checking that could usefully be done at compile time to run time. For example, you've created a possible error condition (object isn't of one of the acceptable classes) that you then had to write code to check for. Plus you had to waste keystrokes on a lot of ugly casting.
>
> There's usually a better choice that gives you at least some compile time checking. Possible choices that spring to mind:
>
> 1. -(id) initWithString: (NString*) aString attributes: (<some class>*) itsAttributes
>
> and passing nil for the 2nd parameter when initializing with just a NSString.
>
> 2. -(id) initWithCFAString: (CFAString*) aString
>
> and modify the CFAString class to encapsulate regular NSString too (perhaps by having attributes == nil).
>
> 3. -(id) initWithMyString: (MyString*) aString
>
> (if you can't change CFAString) and write a MyString class that wraps the functionality of both NSString and CFAString.
>
> Of course, in the context you're dealing with, it may be that your original solution is best, but it's worth considering other choices, if you haven't done that already.
>
>
> _______________________________________________
>
> 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
_______________________________________________
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