On Wed, Mar 19, 2014 at 12:14 AM, Sixten Otto <hims...@sfko.com> wrote:
> On Tue, Mar 18, 2014 at 7:29 PM, Luther Baker <lutherba...@gmail.com> > wrote: > > > A _better_ analogy to an Objective-C @protocol would be a formal Java > > interface. > > > > Sure. And the same in C# (which the OP was asking about). > > Can't tell if you are agreeing with me or implying that I'm stating the obvious. > > > So, Kyle may have good reasons for his answer - but if I understand the > > essence of your question, I would say yes, a pure "abstract class" (where > > no methods are implemented) or a formal "interface" (where method > > signatures have no implementation) in a language like Java ... would both > > indeed be _similar_ to a formal @protocol in Objective-C. > > > > The significant difference, though, between an abstract class in Java or > C#, and a protocol in Objective-C, is that the former may have substantial > implementation associated with it for the benefit of subclasses, and just > not be directly instantiable. > The original poster's first paragraph uses and defines the phrase "partial abstract class" which is what you're describing here. I think we're all good with what you're saying. But the point to which you are actually responding to is in regard to a point I made in response to Kyle's suggestion which had to do with the author's self described "pure abstract class" which we can infer has NO implementation. Your points are true - but I'm confused as to why you are replying with them. They seem to be qualifying something? If you reread the responses you'll see that we are very specifically talking about the case where NO methods are implemented. And more to the point, I think the original poster already knows what you are saying. I think he is asking for thoughts regarding his approach to simulating a notional Abstract Class via mix of @protocols and @classes in Objective-C. He clearly knows he can't do it with @protocols alone. > > (Something like UIKit's UIResponder might be a good choice for this kind of > thing, if Objective-C supported it: it provides a lot of common machinery > you wouldn't want each conforming class to implement separately, but also > isn't something you'd use on its own.) > > Another way that Objective-C accomplishes some of the same goals is through > delegation. You don't, for instance, subclass a UITableView to provide its > data, you provide a delegate that conforms to UITableViewDataSource; which > protocol does have a couple of required methods. > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
