2012-03-17 13 views
7

Zastanawiam się, dlaczego Apple używa typów danych w Core Foundation, które są typowane do typu wskaźnika, podczas gdy w kakao nie są.Dlaczego Apple wcześniej typedef odniesienia (wskaźnik) typy, ale nie teraz?

Jako przykład odwołujesz się do obiektu UIColor, takiego jak UIColor *, a odwołanie do obiektu CGColor to CGColorRef? Lub NSURL * i CFURLRef? Dlaczego po prostu nie zawsze używać CGColor * i CFURL *? I odwrotnie, dlaczego nie ma żadnych typów, ponieważ nigdy nie masz dostępu bezpośrednio do UIColor lub NSURL?

Albo na przykład, dlaczego jest id i nie id *, ponieważ w rzeczywistości jest to wskazówka i mogą w rzeczywistości być typecast do void *?

W szczególności, czy jest jakiś powód, dla którego Apple miał zwyczaj robienia tego w starszych wersjach, ale przestał robić to w Kakao? Czy to po prostu kwestia stylu?

+0

Kakao (jako NeXTStep) jest w rzeczywistości starsze niż Core Foundation. –

+0

Ahh nie zdawałem sobie z tego sprawy. Zawsze zakładałem, że to nowsza. –

+0

A teraz, kiedy o tym wspomniałeś, zdałem sobie sprawę, że to część NeXTStep, myślę, że myślałem o nowszych w ramach frameworków Apple. –

Odpowiedz

8

Co powiedział Matt, ale jest w tym trochę więcej.

Typy w API opartym na C pozwalają również ukryć szczegóły implementacji. Na przykład możesz mieć następujące elementy bez zdefiniowania struktury __CFURL w publicznym nagłówku.

typedef __CFURL *CFURLRef; 

Objective-C od dawna te rodzaje funkcji w postaci kategorii, a ostatnio dodana, zdolność do poruszania instancji deklaracje zmiennych z pliku nagłówka. Spodziewamy się, że z czasem wszystkie zmienne instancji zostaną usunięte z publicznych plików nagłówkowych w pakiecie SDK.

Należy pamiętać, że ramy kakao są długie, długie i opatrzone datą CoreFoundation.

Co do tego, dlaczego id jest używane zamiast , które pochodzi z czasów, gdy Objective-C zostało utworzone po raz pierwszy we wczesnych latach osiemdziesiątych. W szczególności pojęcie języka polegało na tym, że tworzyłbyś "układy scalone oprogramowania", które mogłyby być "połączone" jak prawdziwe układy scalone. Celem było utrzymanie bitów C jako szczegółów implementacji, a najlepiej, aby nie były widoczne w interfejsach API.

Jeśli chodzi o to, dlaczego otrzymujesz NSString * zamiast NSString, jest to w dużej mierze spowodowane podstawami języka C. Napisałem fairly detailed answer do nieco innego pytania dotyczącego SO, które jest istotne.

Prawdopodobnie znajdziesz również this answer relevant.

+0

Wow świetna odpowiedź, dzięki :) –

+0

Ah nice @bbum :-). Miałem nawet powiedzieć w mojej odpowiedzi "ale proszę czekać na @bbum mówić"! Próbowałem nawet znaleźć odpowiedź, przysięgam, że napisałeś o "id" zamiast "id *" wcześniej, ale kompletnie nie. Świetna odpowiedź tutaj. – mattjgalloway

1

Powodem NSURL* vs CFURLRef jest to, że jest to po prostu styl kodowania. Cocoa jest Objective-C API, a ogólny styl w Objective-C polega na tym, że nie ma on typedef, podczas gdy Core Foundation to C API, a ogólny styl polega na użyciu typedef. To zależy od stylu kodowania.

id vs id* - Nie jestem do końca pewien, z tym, ale wydaje mi się, że to historyczny i po prostu chciał mieć zasada „obiekt”, aby być bez *. Nie wiem jednak na pewno o historii tego. Ale znowu będzie to tylko styl.

Powiązane problemy