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

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27322

            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
methods 
(it's need if you decide leave class methods in protocols for backward
compatibility)

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
used.
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
`-instanceConformToProtocol:`.
[MyViewController classConformToProtocol:] and [[MyViewController class]
instanceConformToProtocol:] give the same result.
I think `+conformToProtocol:` should be deprecated, because it adds confusion
here.

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

@end

@interface _MyClass : NSObject
@end

typedef _MyClass<MyClass> MyClass;

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

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

I suggest make
@interface MyClass : NSObject<MyClass>
@end
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>
@end
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>