Re: compile error when protocol not implemented?
Re: compile error when protocol not implemented?
- Subject: Re: compile error when protocol not implemented?
- From: Rua Haszard Morris <email@hidden>
- Date: Thu, 14 Aug 2008 16:33:39 +1200
I figured this must be the reason.. thanks for the detailed
explanation. It did occur to me when i'd implemented the protocol
method but hadn't yet declared conformance.
At the moment this is a zero-warnings build so the warning stands out
almost as much as an error...
I guess a potential language feature would be some kind of option/
keyword in a protocol declaration to say "this protocol must be used
in an old-school, compile-time-typesafe way". But only objc newbies
would want to use it, right?
thanks
On Aug 14, 2008, at 4:18 PM, Michael Ash wrote:
On Wed, Aug 13, 2008 at 8:39 PM, Rua Haszard Morris
<email@hidden> wrote:
I'd like to get an error, not just a warning, when I pass an
instance of a
class to a method that takes a parameter conforming to some
protocol, and
the passed object does not implement the protocol. Is this
possible? Is
there a good way to set things up so an error is generated.. or is
there
some dynamism reason why a warning is more suited?
As far as I know, there's no way to make this one thing into an error.
Objective-C is based around the idea of duck typing. This is just a
funny way of saying that the type of an object is irrelevant. All that
matters is what methods it implements (i.e. what it can do; if it
looks like a duck, quacks like a duck, then it's a duck). As such,
*all* static typing information in an Objective-C program is strictly
advisory in nature. Code like this is perfectly legal, although weird:
NSString *array = [NSArray arrayWithObject:@"hello"];
NSLog(@"%@", [array lastObject]);
Now, protocols are supposed to *be* an indicator of capabilities
rather than of type, but the same principle still applies to the use
of protocols as part of static types. For example, you could implement
the protocol methods without actually declaring conformance to the
protocol.
That said, good code should compile with no warnings anyway. I don't
treat warnings much differently from errors. Occasionally I will
tolerate a warning during development, for expediency or to denote
something that I need to change later, and I am occasionally forced to
accept warnings in external code that I didn't write but that I
compile, but overall I treat warnings the same as errors, so the
difference is not all that important to you.
If you follow this approach but still want an actual stop-the-compile
*error*, then you may be interested in the -Werror flag. This turns
*all* warnings into errors, not just this one, but then again that may
very well be a good thing.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden