objc-zen / objc-zen-book Goto Github PK

Hey,
Is it a personal preference? Or there is a reason I miss somewhere.
Thanks.

Although NSMutableArray *aMutableArray = [@[] mutableCopy]; is not recommended, the code below is appropriate:

NSMutableDictionary *aMutableDictionary = [@{@"Key":@"Value",
                                             @"AnotherKey":@"OtherValue",
                                             @"SomeOtherKey":@"SomeOtherValue"} mutableCopy];

if (SomeThingWrong) {
    aMutableDictionary[@"Error"] = @"ErrorDescription";
}

It's poor reading experience on Github, If you want I can help

You state that private methods should never be prefixed with a single underscore, but the section about use of the pragma directive includes an example of a private method thusly declared:

#pragma mark - Private

- (void)_privateMethod { /* ... */ }

That's a little off-putting in an otherwise excellent guide.

In the section of https://github.com/objc-zen/objc-zen-book#constants, we should not use static for NotificationName, or we can' t extern it for other code. For example:

//a.h
extern static NSString *const TestConstNotificationName;

//a.m
static NSString *const TestConstNotificationName = @"TestConstNotificationName";

This won't pass compile.

On other hand, a constant will be init in the global memory area. So it doesn't need a static key word.

I know this project is about coding convention, but you tried to explain block and its usage, so I ask

In the "Block" section,

__weak __typeof(self)weakSelf = self;
__strong __typeof(weakSelf)strongSelf = weakSelf;

Why typeof(weakSelf) instead of typeof(self)? Aren't they the same thing ?

https://github.com/blog/1184-contributing-guidelines

I think https://github.com/objc-zen/objc-zen-book#multiple-delegation part of article should mention NSHashTable as a way to store weak references without creating ZOCWeakObject class.

In the section on protocols, the book states:
"A great miss in the Objective-C world is the outcome of the latest decades about abstract interfaces. The term interface is typically used to refer to the .h file of a class but it has also another meaning well known to Java programmers which is basically used to describe to a set of methods not backed by a concrete implementation. "

This is not accurate. In objective-c class clusters provide abstract interfaces (and are, usually, abstract factories). NSString, NSNumber, etc. are all abstract interfaces implemented as class clusters. Several framework classes allow specific class clusters to be extended at runtime (NSURLProtocol, etc.).

https://developer.apple.com/library/ios/documentation/general/conceptual/devpedia-cocoacore/ClassCluster.html

In contrast, a protocol only defines a set of messages that an object can choose to implement.

https://developer.apple.com/library/ios/documentation/general/conceptual/devpedia-cocoacore/Protocol.html#//apple_ref/doc/uid/TP40008195-CH45-SW1

clang version: Apple LLVM version 8.0.0 (clang-800.0.42.1)
Xcode version: 7.3.1

NSURL *url = ({
    NSString *urlString = [NSString stringWithFormat:@"%@/%@", baseURLString, endpoint];
    [NSURL URLWithString:urlString];
});

compiler error: initializing 'NSURL *__strong' with an expression of incompatible type 'void'

The value of the latest statement is not returned if enclosing in round bracket.

I would recommend something like “Creative Commons Non-Commercial Share Alike 3.0”.

http://creativecommons.org/

This imply that in your designated initializer you should always call another secondary initializer or your self designated initializer.

Do you mean:

This imply that in your secondary initializer you should always call another secondary initializer or your self designated initializer. ?

Hi, with KVC, we have another option mutableArrayValueForKey, mutableSetValueForKey to add object to the immutable collection

Extract from the Core Data 2nd book, section Mutable Access of To-Many Relationships

You might notice that the NSSet we get back when accessing a to-many rela- tionship is immutable. Adding an object to a to-many relationship with an immutable NSSet requires creating a mutable copy of the NSSet, adding the new object to the NSMutableSet, and setting the NSMutableSet back onto the parent object. It’s a painful process and, fortunately, unnecessary. When we want to add an object to a to-many relationship, we can use -mutableSetValueForKey: in the place of -valueForKey:. This returns an NSMutableSet for us that is already associated with the parent object and reduces our code to the following:

NSManagedObject *newIngredient = ...;
NSManagedObject *recipe = ...;
NSMutableSet *ingredients = [recipe mutableSetValueForKey:@"ingredients"]; 
[ingredients addObject:newIngredient];

Note that we did not need to set the NSMutableSet back into the entity, and therefore the code to add an object to a to-many relationship is quite short

What do you think?

Say you have a class like this

@interface User
@property (nonatomic, strong) NSArray *books;
@end

How do you add an object to books?

When you define you own NSNotification you should define your notification's name as a string constant. [...] The value of the constant should be a reverse DNS identifier.

What is the rationale on this? Why isn't the three-letter prefix enough?

The sentence:

Any property that potentially can be set with a mutable object (e.g. NSString,NSArray,NSURL) must

implies that NSURL have a mutable counterpart. Unless I have missed something, that's not the case and NSURL should be omitted from the example.

In # Class > ## Class name:

There is another good practice that you might want to follow while choosing while naming you class that is, when you're creating a subclass

You wrote:

The interesting part is that the init implementation of NSObject is simply returning self, this is because the variable self is written after the alloc method where all the initialization logic is done.

I think this is not correct or at least confusing. There is nothing special happening between alloc and init that causes “the variable self is written after the alloc method”. alloc simply returns a pointer to the memory it allocated. By sending any message (init or not) to this pointer, objc_msgSend() assigns it to self in the context of the method that was called.

This is also needed to allow the NSObject's subclass to follow the previously exposed pattern.

I donʼt understand what you mean by this sentence.

There is another important part of the contract with init: the method can (and should) signal to the caller that it wasn't able to successfully finish the initialization by returning nil;

Correct. There is another reason why self = [super init] is necessary. Initializers are allowed to return a different instance than the one they have been called on. This is done by re-assigning self in the initializer. Some Cocoa classes use this to return the same instance for identical (immutable) objects. For example, allocating two NSNumbers with the same value (say, @3.14 and @3.14) will return the same instance (ignoring tagged pointers for the moment).

Never prefix your private method with a single underscore _

- (void)_notifyDelegates {

The two lines above are just copied here.

- (void)giveMeFive 
{
    NSString *foo;
   #pragma unused(foo);
   return 5;
}

replace

- (NSInteger)giveMeFive 
{
    NSString *foo;
   #pragma unused(foo);
   return 5;
}