Re: Newbie questions
Re: Newbie questions
- Subject: Re: Newbie questions
- From: Joe Osborn <email@hidden>
- Date: Tue, 7 Jun 2005 03:03:54 -0500
Hi folks,
Hello!
My name's Andy and I'm a Mac developer ("Hi Andy!"). This is my
first visit to this forum.
Hi, Andy! Welcome to Cocoa-Dev, and welcome to Cocoa!
I'm redesigning several data classes. Some people say always
subclass NSObject, others say only do this if you really need to.
My feeling would be to use NSObject as the superclass, is this a
bad idea? What are the advantages/drawbacks/options?
Most arguments against subclassing are against needless subclassing
in the 'view' area of the model-view-controller trinity, about which
you can read in The Objective-C Programming Language. If you are
creating a new class, you /almost always wants to subclass
NSObject/. There are exceptions, but these tend to be blazingly
obvious(i.e., I want an NSTableView that interprets keyboard input
differently). In general, 'new class' -> 'new NSObject subclass'.
Another important note is that it's best not to think in terms of
'data classes', but 'objects'. I know it sounds a semantic
distinction, but once you get away from the idea of, in the words of
Dan Ingalls, "A bit-grinding processor raping and plundering data
structures," " [you] have a universe of well-behaved objects that
courteously ask each other to carry out their various desires."
A lot of my classes contain string data. With PP I would use
embedded objects (e.g. LStr255 mAddress;) in my data record
classes, with different subclasses for different data lengths (e.g.
LStr31 for strings that I knew couldn't be more that 31 characters
long). I was told that Cocoa did not use classes like this and that
I would have to hold just pointers which I would need to create and
delete in the constructor and destructor (or init and dealloc)
functions. Is this true?
Best not to think of them as pointers, but as 'objects', again. I
don't keep track of a pointer to a value of type NSString; I keep a
string. (NSString *) can be read either way, but the latter way is
much more useful. I don't hold a pointer to a value of type NSSet; I
hold an NSSet. The asterisk is, for all intents and purposes, part
of the class name.
As for creating and deleting them, it depends. Some objects you want
to create in your initialization method(please don't call it a
constructor! It's just a Plain Old Objective-C Method, nothing fancy
or magical or automatic) via their class's creation methods, e.g. the
[[SomeClass alloc] init] pair. Some you want passed in as arguments
to the initializer, which you'll keep by sending them [someObject
retain], which indicates a claim of need which is cancelled by
[someObject release] when you're done with it(which can be as late as
the method 'dealloc'). The memory management rules are simple: If
you have retained an object, or created it via alloc or copy, it is
an object's responsibility to later send it as many release or
autorelease messages as it has sent it alloc, copy, and retain messages.
Whichever way I set them up I'll end up with some sort of NSString
objects in my classes. If I can embed them they'll have to be
NSMutableStrings for updating, but if not I could use NSStrings
and, when updating them, release the original and retain the new
one. Would this be a better method (IYOs)?
As I mentioned above, I would normally use different string
subclasses depending on the maximum sizes of the data to be held in
them. Do I need to worry about sizes and storage when using NSStrings?
I'm not sure what IYOs means, but if I have a string that's going to
change, well, I'll call it a mutable string(though your memory
management practices relating to the other string approach are
fine). We Cocoa coders like not to worry about sizes, storage, &c --
remember, an NSString * isn't a char *, so you don't need to worry
about it as much. Using different string subclasses depending on
maximum length, well, that's odd to me.
Another common requirement in my apps is a field to hold money
values. I would store this as a long holding the number of pennies
and use utility classes to format, read and validate it. In all the
money examples I've seen for Cocoa people just use a float and use
NSFormatter classes for UI formatting. I must admit to some
trepidation as I look at floats in the debugger and see 12.00 shown
as 11.9999998, especially as some of my supported apps have big
lists of numbers to be totalled and rounding errors are not
permitted by accountants! Am I worrying needlessly? Anyone have
experience with this?
I would say to use the NSDecimalNumber class. It's a decimal-format
floating point number, so you won't get rounding errors. When you
display, get the decimal number's double value approximation and put
it into a (whatever UI element) with a number formatter and all will
be well.
Thanks for any replies - there will be more questions, believe me.
Hope this is enough to get you properly started.
Cheers
Rev. Andy
__joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden