Oh, noch eine Errungenschaft, die wir wohl Swift zu verdanken haben und die das Coden einfacher macht – dabei aber billigend in Kauf nimmt Falschaussagen zu liefern: Protokolle.
Gegeben sei folgendes Protokoll:
Gegeben seien weiterhin drei Testklassen. Eine implementiert das Protokoll gemäß Header, eine liefert die Methoden im Header und implementiert sie, eine implementiert die Methoden für sich allein ohne im Header darauf hinzuweisen.
Weiterhin gegeben sei folgender Testcode:
Alles anzeigen
Das Resultat spricht für sich:
[NSObject -conformsToProtocol:] testet also entgegen aller Annahmen nicht, ob das Objekt das Protokoll implementiert (a.k.a. im Protokoll definierte Methoden nach außen sichtbar implementiert), sondern ob die Klasse angibt das Protokoll zu implementieren.
Sagt ja auch die Dokumentation.
Klassenorientierter Bullshit.
Gegeben sei folgendes Protokoll:
Gegeben seien weiterhin drei Testklassen. Eine implementiert das Protokoll gemäß Header, eine liefert die Methoden im Header und implementiert sie, eine implementiert die Methoden für sich allein ohne im Header darauf hinzuweisen.
Weiterhin gegeben sei folgender Testcode:
Quellcode
- int main(int argc, const char * argv[]) {
- @autoreleasepool {
- // Instantiate All Of Them
- FooBar * fb = [FooBar new];
- FooBarNonCompliant * fbnc = [FooBarNonCompliant new];
- FooBarConforms * fbc = [FooBarConforms new];
- // Now Check For Response To Selector For Each Method From Protocol
- if( [fbc respondsToSelector:@selector(foo)] && [fbc respondsToSelector:@selector(bar)] ) {
- NSLog( @"FooBarConforms responds to both -foo and -bar" );
- }
- if( [fbnc respondsToSelector:@selector(foo)] && [fbc respondsToSelector:@selector(bar)] ) {
- NSLog( @"FooBarNonCompliant responds to both -foo and -bar" );
- }
- if( [fb respondsToSelector:@selector(foo)] && [fbc respondsToSelector:@selector(bar)] ) {
- NSLog( @"FooBar responds to both -foo and -bar" );
- }
- // Check For Protocol Conformaty
- if( [fbc conformsToProtocol:@protocol(FooBarProtocol)] ) {
- NSLog( @"As I thougt FooBarConforms conforms to protocol" );
- }
- else {
- NSLog( @"FooBarConforms doesn't conform to protocol? What have I done?" );
- }
- if( [fbnc conformsToProtocol:@protocol(FooBarProtocol)] ) {
- NSLog( @"FooBarNonCompliant conforms to protocol? Kewl!" );
- }
- else {
- NSLog( @"As I thougt FooBarNonCompliant doesn't conform to protocol." );
- }
- if( [fb conformsToProtocol:@protocol(FooBarProtocol)] ) {
- NSLog( @"FooBar conforms to protocol. Great!" );
- }
- else {
- NSLog( @"FooBar doesn't conform to protocol. But it should!" );
- }
- }
- return 0;
- }
Das Resultat spricht für sich:
FooBarConforms responds to both -foo and -bar
FooBarNonCompliant responds to both -foo and -bar
FooBar responds to both -foo and -bar
As I thougt FooBarConforms conforms to protocol
As I thougt FooBarNonCompliant doesn't conform to protocol.
FooBar doesn't conform to protocol. But it should!
[NSObject -conformsToProtocol:] testet also entgegen aller Annahmen nicht, ob das Objekt das Protokoll implementiert (a.k.a. im Protokoll definierte Methoden nach außen sichtbar implementiert), sondern ob die Klasse angibt das Protokoll zu implementieren.
Sagt ja auch die Dokumentation.
A class is said to “conform to” a protocol if it adopts the protocol or inherits from another class that adopts it.
Protocols are adopted by listing them within angle brackets after the interface declaration.
Klassenorientierter Bullshit.
«Applejack» "Don't you use your fancy mathematics to muddle the issue!"
Iä-86! Iä-64! Awavauatsh fthagn!
Iä-86! Iä-64! Awavauatsh fthagn!
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
