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 (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/travis%40postfl.com
>
> This email sent to tra...@postfl.com
_______________________________________________
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
