RE: NSDictionary allValues not mutable
Of course it is. Suppose for a minute that [myMutableDictionary allValues] returned a mutable array. That means that you could add to and remove from this array with impunity. Except... the objects in this array are supposed to have an associated key. Um, no they aren't. Arrays don't have keys. What you are returned is an arbitrary array that was initially populated with all the objects in the dictionary. There is no implied linkage back to the dictionary. Adding another object to the dictionary is not going to make a new object appear in the array; why should adding an object in the array make it appear in the dictionary? (Note, adding an object to the dictionary might make the *property* allValues return something different, but that's a different topic) ___ 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
RE: First trials in Cocoa app
If that's not possible, how can I define a function that can reach the objects of my application? The ViewController is stored in the ApplicationDeletegate, but I can't find any reference to that object. Ummm, is this really hard? id MyAppDelegate = [[UIApplication sharedApplication] delegate]; Am I missing some subtlety here? ___ 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
RE: case-insensitive but case-ordered sort
aAbBcCdDeEfF .. etc with everything outside the letter space sorting 'naturally' and coming after the letters (I actually don't care too much about the last bit honestly they can go where they like as long as it's outside the alphabet range). so myClass comes before MyClass which comes before yourClass which comes before YourClass I had to solve this for a different system (sadly, I can't share code) and the first problem you face is that you need to be more specific with your rules than what you have. We sorted A before a, but have the following rules: * Aa * Ab a * Ab aa * Ab ab * Ab ad * Abc ab and it turned out that you can't compare one character at a time. Sometimes you need to look further along the string to decide what your relative orders are. (Note, our compare also handled numerics inside the string as well. This was all complicated enormously because our users think that File-1 File-2 but -2 -1 ... think about it) Our approach was to skip over ambiguous matches (ie, treat A==a) until you find a difference, or decide that the strings are the same. If the tails are different, return that difference. Otherwise return the difference in the *first* ambiguous match you found. ___ 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
RE: Private ivars, not marked as IBOutlet, visible in IB
Not necessarily true. While you are free to specify a delegate as NSObject YourProtocol, it is not standard convention. The convention for delegates is: idYourProtocol. As I recall, sending variables of type idYourProtocol useful messages like retain and release generate a compiler warning, whereas NSObjectYourProtocol are fine. I could be wrong on this, but I definitely recall thinking it was a stupid compiler behavior. However, being totally anal, if you are going to document to the caller all the protocols that you require an object to respect, you should do it properly. Which probably means using idNSObject,YourProtocol - if you put it in a dictionary, you need NSCopying, etc. ___ 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
RE: Private ivars, not marked as IBOutlet, visible in IB
I could be wrong on this, but I definitely recall thinking it was a stupid compiler behavior. This is because you didn't declare your protocol as extending the NSObject protocol. If you do something like this: @protocol MyProtocolNSObject Then you can call all the NSObject stuff without warning. But my protocol only wanted to define the methods in my protocol - a nice clean Interface definition that's independent of all other definitions. After all, Apple might add some non-optional methods to NSObject (ok, that's unlikely) that all objects implementing my protocol would suddenly fail to compile on. Objects could implement MyProtocol *without* implementing NSObject and still be completely useful functionality. They just couldn't be used by code that has chosen to do *other* things to them as well. To keep the discussion from descending into the foolishly abstract, consider NSCopying as the protocol instead. If I want to let you know that the delegate will be stored in a dictionary, I would define the delegate as idMyProtocol,NSObject,NSCopying. Would you seriously think it was a good style to declare @protocol MyProtocolNSObject,NSCopying ? In my opinion, this is a case where interface definitions are being specified badly to get around an implementation problem. Sure, the delegate they pass in will *probably* be a subclass of NSObject but its not a given, as far as the compiler is concerned. If it must be, then declare it properly. I don't think people understand that idNSObject,MyProtocol specifies a hell of a lot less than NSObjectMyProtocol - all the categories on class NSObject for a start. ___ 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
RE: Bison/Yacc with Objective-C ?
I haven't tried it, so this might be nonsense, but I think that YACC
simply copies the emitted code from the source file to the final C
file.
Yacc has to parse the emitted code enough to be able to replace references to
$$, $1, etc with the corresponding tokens from the recognized grammar element.
for example, a grammar I have lying around contains:
enum_mulable: enum_or_int
| '(' enum_expr ')'
{ $$ = $2; }
;
enum_or_int:INTEGER
| '-' INTEGER
{ $$ = -$2; }
| IDENT {
int value;
if (is_enum($1, value)) {
$$ = value;
} else {
lexerror_nl(%s is not a
constant,$1);
$$ = 0;
}
}
;
Yacc changes those $ expressions into references into its value stack.
Thus, Objective-C may trip it up, but then again it may not.
___
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
RE: [[Class alloc] init] preferable over [[Class instance] retain]?
For example, is: NSMutableArray *anArray = [[NSMutableArray array] retain]; better than: NSMutableArray *anArray = [[NSMutableArray alloc] init]; I've been reamed, in the recent past, for expressing the opinion that the first was just as good as the second - apparently the answer depends on what platform you're on. The upshot was that apparently the iPhone developers like you to avoid the use of autorelease pools where possible. One hidden difference in the above is that in the first case you have (probably) populated the autorelease pool and in the other you (probably) haven't. I say probably because you can't know for sure in the majority of cases (its not explicitly documented). And there are aberrant cases like NSDateFormatter whose -init creates a bunch of autoreleased objects that you never see. (When worrying about memory usage, don't blindly trust documentation or heresay. Use Instruments!) Orthogonally, there are classes like NSPredicate where you don't have a choice - there are only convenience methods, no initPredicateWithFormat: ___ 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
RE: Looking for info on anti-piracy and trial-mode techniques for my app . . .
Part of your response suggests that if there was an existing framework that was openly available, it wouldn't do me any good because the bad guys would have the source code. I disagree. If it's based on a tried and tested (and occasionally formally verified) crypto system, knowing the algorithm doesn't lead to a crack. I think again here that the problem is conflating encryption to be the same as DRM. Having encryption schemes in public source means that they can be analysed by the types that truly understand the math. This is a good thing(tm). Having a DRM scheme in public source means that you've handed the hacker all the entry points she needs to consider to bypass your scheme. Specifically, if you rely on private-key signing, you're screwed because the hacker can analyse the open source, determine where the public key comes from, create her own key-pair, patch you to use her public key instead, then use her private key in her keygen which she distributes. ___ 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
RE: NSDictionary trouble
I think dictionaryWithCapacity should both alloc and init it, right? Yes, and it autoreleases it too. :-o That means it'll conveniently be released later on, which is exactly what you're running into. If you want to keep a reference to the dictionary, you should call alloc and init yourself. No, you should just *retain* the result of dictionaryWithCapacity. ___ 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
RE: NSDictionary trouble
Yes, and it autoreleases it too. :-o That means it'll conveniently be
released later on, which is exactly what you're running into. If you
want to keep a reference to the dictionary, you should call alloc and
init yourself.
I wrote:
No, you should just *retain* the result of dictionaryWithCapacity.
mmalc wrote:
No, you shouldn't.
With all due respect, why not? Apple gives us all those convenience methods
but you say we shouldn't use them?
(Note, my first kneejerk response was of course because I'm sure you'll find
Apple docs that say explicitly if you want to keep a reference to x, you
should retain it whereas it's unlikely you'll find anything that says if you
want to keep a reference to x, you're probably using the wrong design
pattern)
(Oh, and, dictionaryWithCapacity: is really not one I'd get in a fuss about.
But some of the other dictionaryWithObjects: convenience methods are too damned
handy to lose. I just don't think that best practice should be something
that changes depending on which particular convenience method you are talking
about)
If you're writing an init method and want to assign the dictionary to
an instance variable, you should use alloc/init.
If you want to assign the dictionary to an instance variable, you
should use an accessor method. In this case, it's still better to use
alloc/init then release the dictionary when you've finished with it.
That's seems a really aberrant case, where you are creating an empty dictionary
with a nominated capacity. I can't visualize a case where you would do such a
thing, outside of the initialiser.
If you want to create the dictionary, use it temporarily, then forget
about it, then dictionaryWithCapacity is OK, but again (particularly on
iPhone) best practice is still to use alloc/init+release.
There are cases like the NSFileManager where you need to pass in a dictionary
of options that describe the directory being created (for example) - should I
really be creating temporary variables for those, or using the convenience
methods (dictionaryWithObject:forKey:)?
I'm assuming you are saying 'don't use the convenience methods because the
autorelease pool won't empty quickly enough'. Certainly Ken said it, though he
seemed to assume that there was only one pool, that people would not be
creating their own in their known trouble-spots.
Ken Thomases wrote:
The autorelease pool is convenient and in some cases necessary, but it
does come at some cost. It has some overhead in terms of time and
memory, plus it tends to increase the peak memory usage of your
program. (Over time, assuming you've got all your memory management
correct, a program's memory usage will come out the same, but
autoreleased objects accumulate over the lifetime of the current pool,
causing spiky memory usage.)
But implicit in that seems to be that -[NSDictionary initWithObjectsAndKeys:]
won't add to the auto-release pool and I don't see where that's a valid
assumption (or at least a documented assumption). If you look at some of the
stack traces in Instruments, you find things being created way down in the
bowels of the frameworks that you wouldn't necessarily expect. (Date
Formatter, I'm looking at you)
I'm increasingly of the opinion that to be properly paranoid (that is, to not
assume anything about the behavior of 3rd party (including Apple) classes) and
survive in the limited memory world of the iPhone, you should be writing your
initialisers like this:
- (id)initLikeJeffThinksYouShould
{
if (self = [super init]) {
// Assume incompetence in others and you'll never be disappointed, only
pleasantly surprised.
NSAutoreleasePool *pool = [NSAutorelease pool new];
_var = [[SomeoneElsesClass someMethodWhichMightFillThePool] retain];
[pool drain];
}
return(self);
}
That's all putting aside that by calling dictionaryWithCapacity: it seems to me
that the NSMutableDictionary framework has more chance of re-using one it had
lying around in some cache - yes, initWithCapacity: could do that as well, but
there would still be the memory-churn expense of the alloc/release that would
not be needed by dictionaryWithCapacity
It might not do it today but if I give the system the clearest possible
indication of what I want (and not just the steps I think it should go
through), I leave more scope for clever software engineers to add extra
optimizations under the covers in future revisions.
___
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
RE: copyWithZone - if anyone could explain this to me ?
In most cases, yes. However, copyWithZone: is special, the superclass' implementation just blindly copies all of the raw bits in the source object to the newly created one. If you were to use the normal -setImage: call, that old value would be released one too many times. Assigning to the instance variable in this case is the way to avoid that. Why would you not just do: [cell-image retain]; That makes it a lot clearer to me - since it was a bitwise copy, cell-image and image are identical values whereas the assignment looks like you are changing something. ___ 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
RE: copyWithZone - if anyone could explain this to me ?
Why would you not just do: [cell-image retain]; That makes it a lot clearer to me - since it was a bitwise copy, cell-image and image are identical values whereas the assignment looks like you are changing something. Because it may *not* have been a bitwise copy. The superclass may have either done a bitwise copy of the whole object (the common case, I believe) or it may have only copied its *own* instance variables (in which case, cell-image will be nil). It's because of this uncertanty of which method the superclass uses that this, admittedly ugly, bit of code is used. Ah, the penny drops. You're saying that the superclass might have used, pseudo-codingly, memcpy( newobj, oldobj, sizeof(typeof(oldobj)) ) rather than memcpy( newobj, oldobj, sizeof(oldclass) ) and thus the newly created object *might* have essentially random bits in the subclass instance variables. I was assuming it was always going to use the latter - seems stupid to use the former under any circumstance. It's never going to be valid for a superclass to make assumptions about the behavior of its subclasses, and thus it's completely irrational to present them with an indeterminate state, when it could just as easily promise all your instance variables will be nil. ___ 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
RE: Code Sign verification on Leopard
Actually, heck, you wouldn't even need that. All a virus would have to do would be to move the binary somewhere else and put a binary in its place that does something malicious and then launches the real binary, and the user would never tell the difference. Unless, of course, the app checked its code signature. Ok, I'll bite. How does the real binary checking its code signature detect the case you just described? Its 100% byte for byte the original executable, its just been moved somewhere else and as far as I'm aware, code signatures do not include your location on disk. ___ 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
RE: When do I need to override hash?
OK, so this discussion is getting a little crazy :-) Agreed. The -hash method is important for objects that are used as keys in associative collections. [snip] So, in practice, it's perfectly safe in 99.9% of cases to base your hash off your object's properties. In the specific case when you're mutating objects that are keys in associative collections (NSDictionary and NSSet being the primary examples, along with their CoreFoundation counterparts) ... Is there any way that you can tell that some higher-level technology you are using (CoreData?) is putting your objects into an NSSet? That's presumably a hidden implementation detail which you can't assume one way or the other with any safety? ___ 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
RE: When do I need to override hash?
Core Data doesn't use random objects as keys in dictionaries or sets for this reason. It's not that we don't trust you, but ... to prevent misunderstandings, all NSManagedObject subclasses are forbidden from overriding -hash and -isEqual. I have to admit, I didn't know this bit but I see it in the developer library along with a bunch of others. If you need to know whether or not another object has put your object into an NSDictionary, you're probably doing something wrong. Do you have a specific concern about Core Data using your objects ? No, I guess the point I was trying to make was that this discussion seemed to have touched on if you put your objects into an NSSet then you'll need to be more careful about the implementation of -hash, etc. I was trying to point out that just because my application code doesn't go anywhere near NSSet, its conceivable (to me) that Core Data (for example) might be storing dirty objects in an NSSet behind your back. So you can't not implement -hash, etc properly and hope everything will work. There may be any number of external technologies (Core Data was just an example) that may be using your objects in ways you aren't expecting, and there's no future-proof way you can cut corners. ___ 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
RE: When do I need to override hash?
Separately, collections may (and presumably sometimes do) use *object* hash values to distribute objects in memory. (Obviously, NSSet does, and for all we know NSDictionary does too, to distribute object values that stored under the same key hash value -- though it would be an implementation detail.) Without wanting to keep the thread going forever, can I just ask why we would presume this? In fact, if I were implementing NSDictionary I'd assume the reverse, that I was not allowed to assume that an objects hash would not change. Is there some documentation on this restriction on the types of objects that can be put into an NSDictionary? I can see the NSSet dictates that objects must implement hash and isEqual: but NSDictionary only says that internally a dictionary uses a hash table - there are limits on the keys, which must conform to NSCopying,etc but I can't see anything about the values. Surely using an NSSet as bucket storage, for all objects whose keys hash to the same value, would add additional restrictions to NSDictionary that should be documented? ___ 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
RE: literal strings - who do they belong to?
Unfortunately, this contract isn't always followed. Lots of people
optimise away this policy instead of doing a superfluous 'return
[[foo retain] autorelease]'.
On initial read, I didn't quite follow this. If my method is returning a foo
that I know I have retained, what requirement is there on me to bump the
retain count temporarily?
Even if I have an object whose nominal retain count is zero (ie, its going to
disappear on the next autorelease-pool-drain), surely the superfluous [[foo
retain] autorelease] only gives it a life while its in the stack frame, which
is to say nothing extra. Its not my problem if the guy who called me has his
own pool that will be free'd when he returns?
But then I saw the case where I have an object which returns, as a method
result or a property, one of its instance variables. The caller holds on to it
(without retaining it) then releases (and deallocs) my object. My object
releases its instance variables which results in the caller holding a reference
to a dead value.
{
Object *o = [Object new];
NSString *s = o.somevalue;// gets o's instance variable (without
retain)
[o release]; // o's instance variable is released
NSLog(@Crash: %@,s) // accesses dead string
}
So, yes, the retain/autorelease isn't superfluous at all, though the usage
pattern that would trigger the problem seems relatively unlikely (in my
example, o seems far more likely to be autorelease'd). Is there a more common
case that I'm missing?
___
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
RE: literal strings - who do they belong to?
be made to behave correctly anyway. For example, you'd never do a
thing like this:
{
NSData *data = [[NSData alloc] initWithBytes:foo length:bar];
const char *bytes = [data bytes];
[data release];
CrashByDoingSomethingWithBytes(bytes);
}
Why should this sort of thing be expected to work, just because the
property in question happens to be an object?
Correct, I'd never do that. I know accessing NSData's internal bytes array is
definitely something that I wouldn't expect to work - that 'const char *' out
the front of -bytes tells me that I don't get to own those bytes. So I
wouldn't have done it, nor expected it to work.
Apples memory rules are explicit and short, and should never be re-stated
because you'll always get it wrong - here's Apple's webpage:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
... if you need to store a received object as a property in an instance
variable, you must retain or copy it.
Thus, apparentl doing
NSString *s = someobject.somevar;
is essentially against the rules. You should always use
NSString *s = [[someobject.somevar {retain|copy}] autorelease];
(To my eye, not common sense, but understandable)
Quoting Peter Lewis: if you want to keep it, retain/copy it applies, even if
you are only going to keep it for the duration of the current method in a local
variable. This is something I wasn't completely conscious of.
If everyone adhered to that particular rule then it seems there would be no
need for the superfluous retain/autorelease in all accessors. However they
then go on to say:
A received object is normally guaranteed to remain valid within the method it
was received in (exceptions include multithreaded applications and some
Distributed Objects situations, although you must also take care if you modify
the object from which you received the object). That method may also safely
return the object to its invoker
which touches on one of my favorite sore-points that has been hashed out time
and time again in the past, that calling 'release' on an object means
modifying it - my example definitely released the object and knew it was
doing it. I can certainly visualise a scenario where retrieving property V
from object A might actually result in the retrieval of some hidden
implementation-specific object B's instance variables which I have no knowledge
of. I can't tell what actions I perform on A which might cause B to be
dealloc'd and thus invalidate the value of V, even if they didn't seem to
modify A.
However, the last sentence about the method being able to return the object to
its invoker is just bizarre - it glosses over things like 'this method has an
autorelease pool', etc. I would have thought that it makes more sense to
simply state that you should [[o retain] autorelease] anything you want to
return at all levels, rather than implicitly insisting that the bottom level
will have done it.
If you always obey the if I stored it in a local variable, I must retain it
and thus arrange for it to be released, then the only way you could return it
to your caller would be from that local and thus it would be legal. So, a
method may safely return the object to its invoker either:
a) directly.return [someobj foo];
b) indirectly.NSObject *val = [[[someobj foo] retain] autorelease];
return val;
Technically those are the only ways you are allowed to retrieve the value then
return it and in both cases there is zero change in 'retain count' and the
object remains alive as per Apples rules.
Jeff Laing je...@spatialinfo.com
--
A complex system designed from scratch never works and cannot be patched up to
make it work. You have to start over, beginning with a working simple system.
-- J Gall. Systemantics: How systems work and how they fail
___
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
RE: literal strings - who do they belong to?
According to Cocoa/ObjC memory-management, if you get an object (reference) via alloc,new,any object that contains copy, and any object you send [object retain] to, is yours - it becomes your responsibility to call [your object release] on it when you're done. Ditto for properties like @property (nonatomic,retain) data typemyProp; where retain is specified. But what about literal NSStrings? Did you get it via alloc, new or copyXXX ? No? No need to release it then! No new rule to remember, no special case to worry about. ___ 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
RE: Clarification on accessors? (was: Yet another memory management question)
Because you have no idea what subclassers may do in their overrides of the accessors Sort of invalidates the whole encapsulation promise of OO design, doesn't it? (e.g. The subclassed accessor may rely on state that's been torn down earlier in -dealloc). But any subclass that's going to override an accessor has had its dealloc method called already, so it should know to have put back anything that matters. Now, if you want to design based on the assumption that everyone else will do a crappy job, that's a different story. It's just not safe, unless you can guarantee that you own the entire inheritance chain. Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was. ___ 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
RE: Clarification on accessors? (was: Yet another memory management question)
No, it doesn't. It would in fact violate the encapsulation principle if your -dealloc method required your accessors to not rely on certain state. The ability to override accessors violates encapsulation because it adds additional restrictions to the accessor that the superclass is not aware of. If you can't write your override of an accessor in such a way that you don't place additional restrictions on the superclass, you shouldn't do it. Because its not possible for you to make the assumption that the superclass will never care - without making (unjustifiable) assumptions about the superclasses implementation. My response was to someone presumably writing about Design Patterns, I believe who wanted to know what was the best approach to take. My opinion is that you should *not* assume that subclassers are idiots, because it doesn't matter how much bullet-proofing you put in, there's always going to be a worse idiot come along. Better to make them all have to work carefully, than to avoid using things *they* might screw up. So you're essentially saying everyone's derived accessors must check if -dealloc has been called and avoid doing anything that might interfere with super's implementation of -dealloc. That doesn't seem tenable. Not everyones - only the ones that know they depend on some complicated local state that they might have screwed up. You can assume that the superclasses state is just fine because he hasn't been dealloc'd yet. Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was. Don't see what the issue is here. As long as -[NSViewController dealloc] doesn't rely on -view -- and it's this independence that we're discussing here -- then you can use it just fine (as long as you do it before calling super's implementation of -dealloc, otherwise all bets are off). As I said, someone more knowledgeable than I needs to respond but as I recall, the issue went that the view controller superclass implemented some sort of additional cleanup that only occurred if you used the accessor to set view to nil. If you just set the instance variable to nil, it would leak. ___ 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
RE: GC pros and cons
I think it depends what language you weaned yourself on. If you've used Lisp or some other functional language, manual reclamation is an unthinkable monstrosity. If you weaned yourself on C or similar languages, manual reclamation seems like the default state of play. Its also going to be an issue whether you are the sort of person who worries at the technical details and fusses over memory footprints (and whether you think those things are important). I had to laugh just yesterday when I came across this article: http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/ (Yes, I do .NET as well as Cocoa) No real surprises there, except for the closing paragraphs which can be paraphrased down to If you need memory to be collected efficiently, you should implement IDisposable and call Dispose() explicitly when you are done with your objects. Which gives a net gain of zero, since you need to call Dispose() exactly where you used to call Release(). To make the automatic model (GC) work efficiently every time, you need to replicate the manual (retain/release) model, all the while presumably telling yourself that this is so much better than what I had. ___ 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
RE: GC pros and cons
Well, no, that's not a good summary of the last couple paragraphs. IF YOU HAVE A FINALIZER, then you should probably be using the Unless you peer into the implementation details of your superclasses, you should assume that all classes may have a finalizer. Unless you don't care about every last little piece of performance. In my day app, we regularly cache hundreds of thousands of objects from a persistent (relational) store and it is absolutely critical to us that the instant that those objects aren't required, they give their memory back - that's how we can run in a machine with only(?) 1 gig of ram. So I'm one of those people I mentioned earlier that really really cares that cleanup happens as soon as possible, not when the fourth or fifth pass through the queue is done. ___ 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
RE: Cocoa and email (SMTP/POP3)
Ok, I'll bite. How does the mail server that Mail.app is talking to distinguish between Mail.app and /usr/sbin/sendmail ? They both presumably just talk SMTP ? If the scriptable solution works, then roll-your-own-smtp should also work, provided you go the hard yards and implement everything it requires (like the tricky authentication stuff). And I'd have thought that /usr/bin/sendmail should do that just fine? Am I missing some subtlety? -Original Message- From: cocoa-dev-bounces+jeff.laing=spatialinfo@lists.apple.com [mailto:cocoa-dev-bounces+jeff.laing=spatialinfo@lists.apple.com] On Behalf Of Nick Zitzmann Sent: Wednesday, 24 June 2009 2:14 PM To: Dave DeLong Cc: cocoa-dev@lists.apple.com Subject: Re: Cocoa and email (SMTP/POP3) On Jun 23, 2009, at 9:42 PM, Dave DeLong wrote: 3.5: Use /usr/sbin/sendmail: Create an NSTask that launches /usr/ sbin/sendmail, configures the headers, and then just pipes your email through the task's standardInput. I can't really recommend doing that in a non-internal app, though, because if the user only has a static IP address and no domain name, then a good deal of mail servers won't accept the mail from the host unless they identify using a fake host name and get lucky. Nick Zitzmann http://www.chronosnet.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/jeff.laing%40spatialinfo.com This email sent to jeff.la...@spatialinfo.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
RE: Cocoa and email (SMTP/POP3)
I won't argue too strongly on this (though I should because I *have* configured sendmail systems and its just not that hard, if you're a developer. And I have rolled my own Perl scripts that talked enough SMTP to connect directly, so its not that big a deal, again for a developer), but my point was that the arguments that said don't use sendmail, it won't get through firewalls that block port 25 are just wrong. Now, if someone had said Apple's default firewall only lets Mail.app connect out through port 25, I'd have gone home and taken a look because I wasn't aware of that capability being in the box. That's why I use Little Snitch. The points being made about some users not having an SMTP-able email server is quite valid. Though people using gmail can still do smtp, as far as I'm aware. http://lifehacker.com/software/email-apps/how-to-use-gmail-as-your-smtp-server-66.php -Original Message- From: Andrew Farmer [mailto:andf...@gmail.com] Sent: Wednesday, 24 June 2009 3:27 PM To: Jeff Laing Cc: Nick Zitzmann; cocoa-dev@lists.apple.com Subject: Re: Cocoa and email (SMTP/POP3) On 23 Jun 2009, at 21:52, Jeff Laing wrote: Ok, I'll bite. How does the mail server that Mail.app is talking to distinguish between Mail.app and /usr/sbin/sendmail ? They both presumably just talk SMTP ? Mail.app is configurable by the user to connect to a specific relay mail server, potentially using login credentials, SSL, and/or an alternate port. Sendmail, by contrast, is not configurable (without cracking open the terminal, at least), and will by default always connect directly to the destination mail server. It's this exact behavior that makes it unlikely to work properly. Consider also that not all users even have Mail.app configured. An increasing number of users use online mail services such as GMail exclusively. In their case, not even scripting Mail.app will help you. If you really need to deliver email notifications from an application, the only reliable solution is to put together a properly secured web- to-email gateway for your application somewhere and use that. Sending email directly from the desktop is no longer a viable solution without explicit configuration. ___ 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
RE: Suppressing variable hiding warning in Xcode
variables hiding instance variables a real nuisance. For example, if you have a message signature with a parameter name which matches an instance variable name, and the compiler produces the following message: warning: local declaration of 'variable name' hides instance variable What really annoyed me was that I had trivial variables called 'mxd' and 'myd' which corresponded to 'movement-x-delta' and 'movement-y-delta'. It took forever to work out that 'myd' clashed with an enum value defined somewhere for Date Ordering - MonthYearDay. (It took so long because Xcode does such a crap job at displaying multi-line error messages, and thus the 'original definition is here' line was nowhere near the 'local names clash' line) In this case, it wasn't instance variables, just locals vs an enum in an enclosing scope. Apple might think about using better (ie, prefixed) names for all their enums if they are going to clash like this, otherwise the set of available variable names is going to evaporate over time... Jeff Laing je...@spatialinfo.com -- A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. -- J Gall. Systemantics: How systems work and how they fail ___ 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
Cocoa Access to iPhone info
My boss has just discovered the iPhone Field Test mode (described here: http://www.wirelessinfo.com/content/inside-the-iphone-field-test-mode.ht m) and was wondering whether there is a mechanism for a regular Cocoa app to get at that Cell information. I'm guessing the answer is no, but I figured I might as well ask. Failing Cocoa, is that info available via some sort of sysctl() or ioctl() interface ? Thanks in advance, Jeff Laing je...@spatialinfo.com -- Remember kids, there are no stupid questions, just stupid people. -- Mr Garrison, South Park ___ 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
RE: Reading one line at a time using NSFileHandle
Is there a way to read one line of a text file at a time using NSFileHandle (the way fgets does)? This code illustrates how you might approach filtering lines of data obtained through an NSFileHandle. I've come across this problem as well - its fine to say read it all into memory, then split it into lines seperated by my arbitrary delimiter, but that doesn't work in small-memory environments (like the iPhone) for big files which would otherwise be fine to parse line by line. Answers of the form ...but how do you know what the delimiter character is, Unicode, blah blah aren't all that helpful. Lets assume that when someone says fgets() they *know* that they want to access an 8-bit ascii, newline-delimited text file line by line. So far, the only answer I've ever seen is to fall back on fopen()/fgets() ___ 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
RE: Enforcing trial software on Mac
I have seen a couple of fairly nice solutions, and lots of really awful ones. Generally speaking, the awful ones try to go to great lengths to be sneaky and hide files or other data in places in your computer they shouldn't be messing with. Its worth pointing out that most hacker-types know about 'fs_usage' - there's little hiding that your app can do without being seen by those who want to know. http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/ fs_usage.1.html Just make the uninstallation process cumbersome enough that people will want to buy your product rather than uninstall/reinstall once a month. Use a real installer, not just drag+drop, so that your install process can write the expiry info into a file that's checksummed/signed however strongly you like. Then, if that file goes missing (say, someone writes a cron-job that runs once a day to remove your file), require a re-install rather than just recreating it. ___ 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
RE: How to create a modal dialog that blocks on start-up?
So what? Implement the appropriate methods in your NSApp delegate, or perhaps a custom subclass of NSDocumentController, and have them stow any arguments and keep reminding themselves using -performSelector:withObject:afterDelay: until conditions change such that the original message can be processed as normal. Why not just have those methods be the ones that display the EULA in a modal window, if required, then continue on as normal (if the user accepts, of course!) ___ 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
RE: Checking for NULL (was Re: Can't get setDelegate to work...)
Mark D. Gerl asked:
There's something that's just uncomfortable about dereferencing
pointers without first checking for validity. Is it just me?
I don't think its just you, though most Cocoa types eventually give up
and go with the simpler 'just trust it, it works' approach. Personally,
I think relying on the 'nil eats all messages' is the road to damnation,
but the Cocoa frameworks do it internally so there's no avoiding it, its
never going to change.
(For the record, when I add an IBOutlet to a class definition, I add the
corresponding assertion that its non-nil to the awakeFromNib method
because I *know* that I forget to connect those things up, and have
wasted days chasing unexpected 'nil' objects)
One thing I wonder about in your example, however, is why you don't have
the else cases populated? (I realise it's a coded-in-email example, but
it's the quality of the paranoia I'm interested in) ie, if I'm going
to be so paranoid as to check that the status bar exists, I'm going to
have a strategy for when it isn't. ie,
if (systemBar != NULL)
{
...
} else {
// what would you put in here to let the user know that
the system has
// gone kablooey?
}
My attitude comes down to unless its going to be a state where the
system is still stable enough to display alert messages, I might as well
just let it dump core - at least that way, I get a stacktrace.
I realise that's a bit radical but I've spent too many years *removing*
badly-formed paranoia from (other peoples) code that did this 'check for
nil' protection but didn't bother propagating the problem out to a layer
that should actually do something about it, instead just returning an
'it worked ok' status.
(Personally, I think this is the only place where throwing exceptions is
truly justified)
But if you aren't going to raise an error somehow, then there's no
reason for not cascading the method calls together. Except perhaps ease
of breakpointing when chasing that elusive failure that couldn't
possibly be in the middle of a complex expression...
___
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
RE: One IBAction, multiple results from multiple methods
That's because you aren't making the point hard enough.
Make the seekForward: method look at the bottom two digits in the ID
of the button. That lets the interface designer has a 1x 2x 4x 8x 16x
seek buttons it he wants to, or just 1x
- (IBAction)seekForward:(id)sender
{
[self seekBy:1+(id 0x0F)]
}
Its putting business meaning into the otherwise abstract 'id' values
but its your application, design it the way you want to and ignore the
purists who would tell that 'its bad'.
-Original Message-
From: cocoa-dev-bounces+jeff.laing=spatialinfo@lists.apple.com
[mailto:cocoa-dev-bounces+jeff.laing=spatialinfo@lists.apple.com] On
Behalf Of I. Savant
Sent: Friday, 27 February 2009 3:12 AM
To: Michael Ash
Cc: cocoa-dev
Subject: Re: One IBAction, multiple results from multiple methods
On Thu, Feb 26, 2009 at 10:53 AM, Michael Ash michael@gmail.com
wrote:
It's true that there are scenarios where dispatching off the tags are
helpful, but I don't think that this is one of them.
You're absolutely right, it's a stretch to use this example because
it's not complicated enough to highlight the point I'm making.
Laziness is my only excuse for not providing a more complex example.
:-)
--
I.S.
___
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/jeff.laing%40spatialinf
o.com
This email sent to jeff.la...@spatialinfo.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
RE: nib loading / displaying question.
How many times will the user display the about panel in an average session of working with your app? Most likely, the answer is once. At the risk of being provocative, I'd say the answer is closer to zero. As such, it's a premature optimisation to worry about it, and we all know Apple's mantra on premature optimisation. ___ 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
RE: Outlets / IBOutlet declarations (was Re: Interface Builder Wiring Objects)
But if your dealloc is like this...
- (void)dealloc
{
self.thisProp = nil;
self.thatProp = nil;
...
}
then you'll be calling the accessors and the right thing will happen
(i.e. release if necessary). This is what I currently do for all dev
work (iPhone or Mac OS X). In fact, I use accessors everywhere and
never do direct ivar access.
My understanding (and I'm a noob in this) is that best practices
recommend that you shouldn't start sending additional messages to an
object from inside its dealloc.
Those property accesses are just candy-coated calls to setThisProp:, etc
which violates the 'don't send message to yourself' recommendation.
Anyone want to clarify if it is/isn't safe to do this? Certainly most
of the samples I've seen go out of their way to release instance
variables rather than nil properties, in their dealloc's
(This is the one thing I hate the *most* about properties - they really
feel glued on, at this point, rather than being a language feature that
the whole compiler knows about)
___
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 [EMAIL PROTECTED]
RE: Outlets / IBOutlet declarations (was Re: Interface Builder Wiring Objects)
On Nov 19, 2008, at 2:29 PM, mmalcolm crawford wrote:
You send a release message to instance variables for which there is a
corresponding retain or copy property.
which is why I originally said:
(This is the one thing I hate the *most* about properties - they
really feel glued on, at this point, rather than being a language
feature
that the whole compiler knows about)
Most of the time you are supposed to think in terms of abstract
properties (so that KVO will work) but in your dealloc, you need to fall
back to worrying about the instance variables used to *implement* those
properties.
If you accept the default behaviour and name your properties the same as
your instance variables, then you don't necessarily notice that it's the
instance variables you clean up. Its really easy to think that
- (void) frammitz { [something foobar]; }
and
- (void) frammitz { [self.something foobar]; }
are *identical* and they are not. The Objective-C designers choice of
'.' syntax, which just *screams* structure-member-access to anyone with
C++ experience makes it even more confusing for those of us who have a
multi-language background.
The phrase for which there is a *corresponding* ... property is the
one I still need to repeat to myself over and over. To a certain
extent, properties are orthogonal to instance variables; you can choose
to implement properties via equivalently named instance variables but
its not a given that you have to. And you can have instance variables
without property definitions.
The @property declaration, where you use an alternate name, seems like
an area for confusion.
@property (nonatomic,retain) NSObject *xxx;
...
@synthesize xxx=_yyy;
...
not only defines accessors for a property called 'xxx', but also defines
the memory retention contract for the instance variable '_yyy'. In the
past, you need only look in your .m file to determine how you needed to
clean up your instance variables irrespective of the public interface
they define in the .h file. Now, you need to look in both the .h and
the .m
As someone else remarked, @synthesize does *most* but not all of the
job, if its job is to 'provide the implementation of the property'. The
reality is that its job is only to 'provide the *accessors* for the
property' which it does do completely. And it does seem like having one
more hack, perhaps
- (void)dealloc
{
@release xxx;
[super dealloc];
}
would make me feel like the feature (properties) was actually complete.
Jeff Laing [EMAIL PROTECTED]
--
The lessons of history teach us - if they teach us anything - that
nobody learns the lessons that history teaches us.
___
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 [EMAIL PROTECTED]
RE: Outlets / IBOutlet declarations (was Re: InterfaceBuilder Wiring Objects)
There's no difference between setting through a property, and setting through a plain old setter method. That said, it's up to you to decide if you want to go with the official recommendation or not. If you think that you have enough control over the implementation of your accessor methods, you might choose to still use them. The question has been related to best practices, which is why I'm pursuing it. As to 'control over the implementation of your accessors', if people use @synthesize (thus taking whatever the compiler gives them) and/or have bindings (or whatever it is) sneaking additional KVO/C stuff in over the top of their accessors, how much information do they actually *have* about their accessors to make an informed choice? ___ 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 [EMAIL PROTECTED]
RE: Outlets / IBOutlet declarations (was Re: InterfaceBuilder Wiring Objects)
From: Roland King [mailto:[EMAIL PROTECTED] I think if you're talking about your own instance variables which you are declaring and synthesizing, you have enough information to decide if it's safe to call your property accessors in dealloc or not. Well, that's sort of my point, really. I don't *know* what happens inside the *synthesized* code, the only thing I can do is look to Apple who do and what they've said in the past is don't do it. Not its not safe. So I don't think I can make my own mind up - Apple has made it up for me, without explicitly telling me what the decision was, only hinting at it. ___ 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 [EMAIL PROTECTED]
RE: Outlets / IBOutlet declarations (was Re: Interface Builder Wiring Objects)
If you declare a property: @property (nonatomic, assign) MyLabel *label1; but make the connection in IB to mLabel1, then the property accessor isn't used. So the outlet is set using setValue:forKey:. Which results in the value being retained, precisely as described in the documentation... http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptu al/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/ uid/1051i-CH4-SW6 How about: http://developer.apple.com/samplecode/CacheInfo-MacOSX/listing1.html (for example) which has the IBOutlet tag on the instance variables rather than the properties; I'll bet its different because properties and instance vars have the same name, isn't it? (Note, this isn't the only one I've seen this pattern in, its just the first that came to hand) That example declares dozens of IBOutlet's, whose properties are (nonatomic,retain) and doesn't release any of them in its dealloc. ___ 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 [EMAIL PROTECTED]
