Am 30.04.2017 um 17:32 schrieb Charles Srstka <[email protected]>:
> I’m sure there’s probably a property somewhere in Foundation that’s marked > atomic, but so far I haven’t been able to find one. Properties that are > marked atomic look like this: There's only 5 that are declared nonatomic, the others do not list nonatomic - making them atomic, which is the default. But they are not actually atomic, as they are implemented using return [[foo retain] autorelease]. > @property (atomic, strong) Foo *foo; > > Properties that are marked “I don’t know whether this is atomic or not, check > the documentation to find out” are marked like this: > > @property (strong) Foo *foo; No, this is not true. The atomic keyword is quite new and didn't even exist initially. atomic is just the default. See also https://lists.apple.com/archives/objc-language/2012/Mar/msg00022.html on the introduction of the atomic keyword. > Foundation almost entirely uses the latter. The reason is because the > properties themselves often predate the @property syntax, being originally > presented as manually-written getters and setters. At some point, they were > converted to @properties, probably in preparation for the introduction of > Swift, since it actually imposes different syntax requirements on properties > and ordinary methods, unlike Objective-C. Since vetting the entire Foundation > framework is a long and arduous task, I assume that the developers probably > reasoned that the documentation had been serving as an adequate reference for > the atomicity of the properties up until that point, and would continue to do > so. Again, this is not really true. When properties were introduced, there wasn't even an atomic attribute. > As for why a property that’s not marked is made atomic if it’s automatically > synthesized? I think that was a poor decision. You certainly can’t rely on > the atomicity of a property so marked; it will only be atomic if the > developer hasn’t provided their own implementation, and even if they *have*, > if their intention wasn’t deliberately to make it atomic, there’s no way to > tell whether they might provide their own accessor in the future and break it. Yep, that is indeed the problem I am pointing out here. They claim to be atomic - while they're not. It's better to declare them nonatomic and still retain + release (worst case then is that you retain more than necessary). That at least doesn't claim something they are not. Declaring them atomic declares them to be something they're not. > Given that, thanks to Foundation, it’s probably safe to say that the vast > majority of unmarked properties are not actually atomic, any property that > presents itself this way must be treated as if it were nonatomic. Yes, because Foundation decided to mark them atomic even though they are not :/. IMHO this breaks the documented API, and atomic (by omission of nonatomic) is part of the API. That was why I raised these questions to John :). -- Jonathan _______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
