OC 및 LLVM의 주요 개선 사항

OC 및 LLVM이 크게 향상됩니다.본고는 이러한 개선에 대해 간단하게 정리하고 평론할 것이다.

방법 순서

다음 코드가 있는 경우

@interface SongPlayer : NSObject
- (void)playSong:(Song *)song;
@end 

@implementation SongPlayer
- (void)playSong:(Song *)song {
    NSError *error;
    [self startAudio:&error];
    ...
} 

- (void)startAudio:(NSError **)error { ... }
@end

이전 컴파일 환경에서, 위의 코드는 [self start Audio: &error] 에서 실례적인 방법에서 찾을 수 없는 경고가 나타납니다.컴파일러 순서 때문에 컴파일러는 -playSong: 방법 뒤에 -startAudio: 가 있다는 것을 알 수 없기 때문에 경고합니다.이전의 해결 방안은 두 가지가 있었다. -startAudio:의 실현을 -playSong:의 위로 옮기거나 분류에서 -startAudio:(겸사겸사 -startAudio:를 직접 가져가라.h 파일에서 완전히 잘못된 방법이다. 왜냐하면 이 방법은 공공이 아니기 때문이다).전자 파괴.m 파일의 구조가 방법 배열의 순서를 어지럽혀 향후 유지보수가 번거롭다.후자는 별도의 불필요한 코드를 써야 한다.m 파일이 길어집니다.사실 두 가지 방법 모두 좋은 해결 방안이 아니다.
이제 더 이상 이 문제를 골치 아프게 할 필요가 없다. LLVM에 새로운 기능이 추가되었다. 이제 위의 코드를 직접 사용하고 추가 처리를 하지 않아도 경고를 피할 수 있다.새 컴파일러는 이전의 순서대로 컴파일하는 행위를 바꾸어 방법에 대한 설명을 먼저 스캔한 다음에 방법에 대한 구체적인 실현을 컴파일하는 것으로 바꾸었다.이렇게 하면 같은 실현 파일에서 방법이 어디에 쓰이든 컴파일러는 방법이 실현되기 전에 모든 방법의 이름을 알고 경고를 피할 수 있다.

열거 개선

Xcode 4.4부터 더 나은 매거진 쓰기가 시작된다.

typedef enum NSNumberFormatterStyle : NSUInteger {
    NSNumberFormatterNoStyle,
    NSNumberFormatterDecimalStyle,
    NSNumberFormatterCurrencyStyle,
    NSNumberFormatterPercentStyle,
    NSNumberFormatterScientificStyle,
    NSNumberFormatterSpellOutStyle
} NSNumberFormatterStyle;

열거 목록을 열거하는 동시에 열거 형식이 NSUInteger로 귀속되어 있습니다. 이전의 직접 열거와 선열거 재귀속 형식보다 컴파일러가 더 정확한 경고를 할 수 있습니다.개인적으로 일반 개발자에게 쓸모가 그리 크지 않다고 생각합니다. 왜냐하면 복잡한 매거진과 관련이 없기 때문에 이전의 매거진으로 설명하는 방법도 헷갈리지 않기 때문입니다.그래서 매거진에 익숙해지면 계속 쓰면 되는데..그러나 조건이 있거나 아직 자신의 습관이 형성되지 않았거나 새로운 공사를 시작하려면 이런 새로운 방법을 시도해 보는 것이 좋다. 상대적으로 엄격하기 때문이다.

속성 자동 바인딩

사람마다 모두property를 즐겨 쓴다는 것은 의심할 여지가 없다.그러나property를 쓸 때는 일반적으로 실례 변수와 상응하는synthesis를 써야 하는데 이것은 정말 사람을 기쁘게 하는 일이다.애플은 최소한 실례 변수를 써야 한다는 요구를 없애기 위해 노력했다.synthesis에서 등호 뒤의 값은 바로 실력 변수명이다.이제 애플은 한층 더 나아가 우리에게 아주 좋은 소식을 가져왔다. 앞으로는synthesis를 쓰지 않아도 된다!Xcode 4.4 이후synthesis는property에 대응하여 자동으로 생성됩니다.
기본 동작에서 속성foo에 대해 컴파일러는 자동으로 실행 파일에서synthesis를 보완합니다. @synthesisfoo=foo;똑같아요.기본 실례 변수는 밑줄로 시작해서 속성 이름을 받습니다.만약에synthesis를 썼다면 개발자가 직접 쓴 synthesis를 기준으로 합니다. 예를 들어 @synthesisfoo만 썼습니다.그럼 실례 변수명은 포오야.만약synthesis가 없고 자신이-foo 및-setFoo:를 실현했다면 이property는 실례 변수에 대응하지 않을 것이다.Getter나setter 중 하나만 실현되면 다른 방법은 자동으로 생성을 돕는다. (synthesis를 쓰지 않았더라도readonly의property는 따로 말한다.)
@dynamic을 쓴 것에 대해 모든 대응하는synthesis는 효력이 발생하지 않습니다. (synthesis를 쓰지 않았더라도runtime의 필연입니다.)다이내믹을 썼으면 setter와 Getter가 실행될 때 정해진 것으로 이해할 수 있습니다.
요약하면 새로운 속성 바인딩 규칙은 다음과 같습니다.

개발자가 실행 파일에 Getter나setter를 제공하지 않으면 자동으로 생성됩니다

개발자가 Getter와setter를 동시에 제공하지 않으면 실례 변수가 자동으로 생성됩니다

synthesis를 쓰면 실례 변수 이름이 있든 없든 실례 변수

를 생성합니다

dynamic 우선순위가synthesis

보다 높음

약자

OC의 문법은 줄곧 비교적 번거롭다고 여겨져 왔고 절대 다수의 메시지 발송은 모두 긴 함수 이름을 가지고 있다.사실 이것은 양날의 검이다. 좋은 점은 코드를 상당히 쉽게 읽을 수 있게 한다. 거의 모든 방법이 완전한 영어로 묘사되고 명칭 규칙을 준수하면 매개 변수의 유형과 방법의 작용도 뚜렷하지만 좋지 않은 점은 코딩할 때 불필요한 키보드를 많이 두드려 개발 효율을 떨어뜨린다.Apple은 이를 깨닫고 새로운 LLVM에 일련의 열 규칙을 도입하여 OC를 간소화했다.간소화를 거친 후 일부 가독성을 낮추는 대가로 개발할 때 조금 빨라진 것으로 바뀌어 현재의 짧은 개발 주기의 수요에 부합된다고 할 수 있다.간략화된 OC 코드의 모습은 Perl이나 Python 같은 빠른 개발 언어에 한 걸음 다가갔고, 실제로 사용하기에 좋은지 나쁜지는 인지가 각기 다르다. 적어도 나는 개인적으로 어떤 간략한 글자를 특별히 좋아하지 않는다..아마도 간략하게 쓴 코드가 아직 직감이 형성되지 않은 것을 보고 잠시 반응해야 이것이 무엇인지 알 수 있을 것이다.

NSNumber

모든 [NSNumber numberWith...:] 메서드는 다음과 같이 간략하게 쓸 수 있습니다.

[NSNumber numberWithChar:'X'] 약자@'X'로 쓰기;

[NSNumber numberWithInt: 12345] 약자 @12345

[NSNumber numberWithUnsignedLong: 12345ul] 약자 @12345ul

[NSNumber numberWithLongLong: 12345ll]로 약칭 @12345ll

[NSNumber numberWithFloat:123.45f] 약칭 @123.45f

[NSNumber numberWithDouble:123.45] 약칭 @123.45

[NSNumber numberWithBool: YES] @YES

로 약자
음.. 편하네~ 예전엔 숫자가 제일 싫었는데 아라에 넣으면 NSNumber로 봉인해야 하는데... 지금은 @로 시작해서 숫자를 받아서 간소화할 수 있어.

NSArray

일부 NSArray 방법은 다음과 같이 간단해졌습니다.

[NSArray array] 약자 @[]

[NSArray array WithObject:a] 약자 @[a]

[NSArray array WithObjects: a, b, c, nil] 약자 @[a, b, c]

@ 기호는 NS 대상을 나타내는 것으로 이해할 수 있다. (NSString의 @ 번호와 같다.) 그리고 많은 다른 언어에서 흔히 볼 수 있는 네모난 괄호 [] 를 연결해서 그룹을 나타낸다.실제로 우리가 간략하게 쓸 때, 컴파일러는 그것을 자동으로 번역하여 우리가 흔히 볼 수 있는 코드로 보완할 것이다.예를 들어 @[a, b, c]에 대해 실제 컴파일할 때의 코드는

// compiler generates: 

id objects[] = { a, b, c };
NSUInteger count = sizeof(objects)/ sizeof(id);
array = [NSArray arrayWithObjects:objects count:count];

특히 a, b, c에 nil이 있다면 NSArray를 생성할 때 이상을 던지는 것이지 [NSArray array WithObjects:a, b, c,nil]처럼 불완전한 NSArray를 형성하는 것이 아니다.사실 이것은 매우 좋은 특성으로 찾기 어려운 버그의 존재를 피한다.

NSDictionary

수조가 간소화되었으니 사전도 틀리지 않았고 Perl아 Python아 Ruby아와 비슷했다. 예상했던 작법:

[NSDictionary dictionary] 약자 @{}

[NSDictionary dictionary WithObject:o1 forKey:k1]약자는 @{k1:o1}

로

[NSDictionary dictionary WithObjects AndKeys:o1,k1,o2,k2,o3,k3,nil] 약자는 @{k1:o1,k2:o2,k3:o3}

로
수조와 유사합니다. @ {k1:o1,k2:o2,k3:o3}을 썼을 때 실제 코드는

// compiler generates:
id objects[] = { o1, o2, o3 };
id keys[] = { k1, k2, k3 };
NSUInteger count = sizeof(objects) / sizeof(id);
dict = [NSDictionary dictionaryWithObjects:objects forKeys:keys count:count];

Mutable 버전 및 정적 버전

위에서 생성한 버전은 모두 변할 수 없습니다. 변할 수 있는 버전을 얻으려면 -mutable Copy 메시지를 보내서 변할 수 있는 복사본을 만들 수 있습니다.예컨대

NSMutableArray *mutablePlanets = [@[
                                  @"Mercury", @"Venus",
                                  @"Earth", @"Mars",
                                  @"Jupiter", @"Saturn",
                                  @"Uranus", @"Neptune" ]
                                  mutableCopy];

또한static로 표시된 수조(static이 없는 사전.. 해시와 정렬은 컴파일할 때 완성되고 코코아 프레임워크의 키도 상수가 아니다)에 대해서는 약자로 값을 부여할 수 없다(사실 원래의 전통적인 문법도 안 된다).해결 방법은 클래스 방법 + (void) initialize에서 static에 값을 부여하는 것입니다. 예를 들어 다음과 같습니다.

static NSArray *thePlanets;
+ (void)initialize {
    if (self == [MyClass class]) {
        thePlanets = @[ @"Mercury", @"Venus", @"Earth", @"Mars", @"Jupiter", @"Saturn", @"Uranus", @"Neptune" ];
    }
}

아래 첨자

이러한 약자를 사용하는 가장 큰 목적은 아래 첨자를 사용하여 요소에 액세스하는 것입니다.

[array objectAtIndex:idx]는 간략하게array[idx]로 쓴다.

[array replace Object AtIndex: idx with Object: new Obj] 약칭array [idx] = new Obj

[dic objectForKey:key] 약칭 dic[key]

[dic setObject:object for Key:key] 간략하게 dic[key] = newObject

편리하지만 사전에 쓰이는 것도 네모난 괄호[]이지 상상 속의 괄호 {}가 아니라는 것을 주의해야 한다.코드 블록의 괄호와 충돌을 피하고 싶었을 텐데.. 간략한 실제 작업 원리는 사실 정말 간단하게 대응하는 방법의 간략한 쓰기일 뿐 놀랄 것이 없다.
그래도 서프라이즈가...그것은 유사한 방법을 사용해서 우리 자신의 클래스에 접근할 수도 있고, 아래 표시를 사용해서 접근할 수도 있다는 것이다.이러한 목적을 달성하기 위해 우리는 다음과 같은 방법을 실현해야 한다. 유사한 수조의 구조에 대해.

- (elementType)objectAtIndexedSubscript:(indexType)idx; 

- (void)setObject:(elementType)object atIndexedSubscript:(indexType)idx;

유사 사전의 구조:

- (elementType)objectForKeyedSubscript:(keyType)key; 

- (void)setObject:(elementType)object forKeyedSubscript:(keyType)key;

고정 브리지

ARC에서 가장 현혹되고 틀리기 쉬운 부분은 대개 브리지 콘셉트일 것이다.역사적 원인으로 인해 CF 대상과 NSObject 대상의 전환은 미묘한 관계가 존재해 왔다. 그러나 ARC를 도입한 후에 이런 관계는 복잡해졌다. 주로 CF가 있어야 하는지 NSObject가 메모리 관리를 맡아야 하는지를 명확히 해야 한다(ARC와 더 자세한 설명은 내가 전에 쓴 ARC 입문 강좌를 참조할 수 있다).
Xcode 4.4 이후 누가 대상을 가지고 있는지 구분하는 일은 모호해진다.코드 블록 구간에 CF 추가IMPLICIT_BRIDGING_ENABLED 및 CFIMPLICIT_BRIDGING_DISABLED, 이전의 브리지 변환은 CF와 NS 사이의 강제 변환을 간단하게 작성할 수 있으며 을 추가할 필요가 없다bridging 키워드입니다.누가 이 메모리를 관리합니까?시스템에 맡기고 골치 아프게~
Objective-C는 확실히 빠르게 변화하고 있는 언어입니다.한편, 그의 동적 특성과 스몰톡의 낙인은 깊지 않고, 다른 한편, 각종 간단한 언어의 문법 방향으로 적극적으로 접근하고 있다.각종 자동화 처리는 다소 불안하지만, 사실은 그들의 업무가 양호하고, 개발자를 위해 시간을 절약했다는 것을 증명한다.빨리 새로운 변화를 끌어안도록 노력하자~