[llvm-bugs] [Bug 27322] New: Objective-C protocol enhancement and abstract classes

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Apr 12 02:47:24 PDT 2016


            Bug ID: 27322
           Summary: Objective-C protocol enhancement and abstract classes
           Product: clang
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Keywords: new-feature
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: su.chan.znak at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Objective-C have not accomplished protocol structure.
There is exist mess, if you want make class object (not object of class) to
conform to protocol.
For example, if I want, that UITableViewDelegate should be implemented by class
methods, not instance methods, then I get set of problems:
1. I shouldn't declare, that my class conform to protocol UITableViewDelegate,
or I'll get methods, that I have unimplemented methods
2. I need write methods with + instead of -, and IDE will not show tips with
method prototypes and I can make typos.
3. As because I can't declare, that class object conform to protocol, I need
use runtime functions, to make `conformToProtocol` work.
4. There is mess with Class<UITableViewDelegate> record. Actually I don't know,
is it class object conform to protocol or it's instances.

What I suggest:
1. Protocols shouldn't have class methods.
2. There is should be syntax that protocol is implemented with class method,
instead of instance methods. I suggest syntax with + and - sign. For example:

@interface MyViewController:UIViewController<+UITableViewDelegate>
thats mean, that protocols methods should be implemented with class methods.

Old syntax without + and - we leave as it was.
Minus syntax used for convenience, In common cases it's like without -,
but it can also force class methods from protocol to be implemented by instance
(it's need if you decide leave class methods in protocols for backward

When work with variables, this code shouldn't show warnings:

id<UITableViewDelegate> delegate = [MyViewController class];
Class<+UITableViewDelegate> classDelegate = [MyViewController class];
//Actually id<UITableViewDelegate> is more preferable, but such syntax can be
delegate = classDelegate;
classDelegate = (Class<+UITableViewDelegate>)delegate;
Class<-UITableViewDelegate> classOfDelegate = [delegate class];
id<+UITableViewDelegate> instanceOfDelegate = [[MyViewController alloc] init];
classDelegate = [instanceOfDelegate class];
delegate = [instanceOfDelegate class];

3. And method in `NSObject` `+classConformToProtocol:` and
[MyViewController classConformToProtocol:] and [[MyViewController class]
instanceConformToProtocol:] give the same result.
I think `+conformToProtocol:` should be deprecated, because it adds confusion

By the way, you can apply +/- syntax for generics:
NSArray<NSString> *arrayOfStrings; //don't need * in <>
NSArray<NSString, -UITableViewDelegate> *arrayOfStringAndTableViewDelegate;

Also there is lack of abstract classes in Objective-C. To make abstract class I
usually write:

@protocol MyClass

//some methods


@interface _MyClass : NSObject

typedef _MyClass<MyClass> MyClass;

@inteface _MyClass() <MyClass> //if I want add some standard implementations

It's really mess, looks ugly, not clear from first view.

I suggest make
@interface MyClass : NSObject<MyClass>
just abstract. What does it mean:
- don't show warnings if some methods not implemented
- don't allow instantiate such class if some methods not implemented (show
error or warnings in place, where user trying to instantiate such class)

but I suggest leave old behavior if protocol is declared in class extension:
@interface MyClass() <MyClass>
shows error and warnings if some methods not implemented

That's it. I hope you will find my ideas as "must have".

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160412/ae24df20/attachment.html>

More information about the llvm-bugs mailing list