[
https://issues.apache.org/jira/browse/THRIFT-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Joseph updated THRIFT-3325:
--------------------------------
Description:
The following interface definition:
{noformat}
service Parent {
string name();
}
service Child extends Parent {
i32 age();
}
{noformat}
Produces the following generated Cocoa (truncated for readability):
{noformat}
@protocol Parent <NSObject>
- (NSString *) name; // throws TException
@end
// ...
@protocol Child <NSObject>
- (int32_t) age; // throws TException
@end
@interface ChildClient : NSObject <Child> {
id <TProtocol> inProtocol;
id <TProtocol> outProtocol;
}
- (id) initWithProtocol: (id <TProtocol>) protocol;
- (id) initWithInProtocol: (id <TProtocol>) inProtocol outProtocol: (id
<TProtocol>) outProtocol;
@end
{noformat}
With these definitions, an instance of "Child" knows nothing of nor can ever
have superclass method {{name()}} called on it. This completely breaks not only
polymorphism, but the use of the "extends" keyword when generating Cocoa.
This could be easily resolved by simply having the "Child" class also conform
to the "Parent" protocol, or more-correctly resolved by making "Child" an
actual subclass of "Parent".
was:
The following IDL:
{noformat}
service Parent {
string name();
}
service Child extends Parent {
i32 age();
}
{noformat}
Produces the following generated Cocoa (truncated for readability):
{noformat}
@protocol Parent <NSObject>
- (NSString *) name; // throws TException
@end
// ...
@protocol Child <NSObject>
- (int32_t) age; // throws TException
@end
@interface ChildClient : NSObject <Child> {
id <TProtocol> inProtocol;
id <TProtocol> outProtocol;
}
- (id) initWithProtocol: (id <TProtocol>) protocol;
- (id) initWithInProtocol: (id <TProtocol>) inProtocol outProtocol: (id
<TProtocol>) outProtocol;
@end
{noformat}
With these definitions, an instance of "Child" knows nothing of nor can ever
have superclass method {{name()}} called on it. This completely breaks not only
polymorphism, but the use of the "extends" keyword when generating Cocoa.
This could be easily resolved by simply having the "Child" class also conform
to the "Parent" protocol, or more-correctly resolved by making "Child" an
actual subclass of "Parent".
> Extended services aren't subclasses in generated Cocoa
> ------------------------------------------------------
>
> Key: THRIFT-3325
> URL: https://issues.apache.org/jira/browse/THRIFT-3325
> Project: Thrift
> Issue Type: Bug
> Reporter: Ryan Joseph
> Priority: Critical
>
> The following interface definition:
> {noformat}
> service Parent {
> string name();
> }
> service Child extends Parent {
> i32 age();
> }
> {noformat}
> Produces the following generated Cocoa (truncated for readability):
> {noformat}
> @protocol Parent <NSObject>
> - (NSString *) name; // throws TException
> @end
> // ...
> @protocol Child <NSObject>
> - (int32_t) age; // throws TException
> @end
> @interface ChildClient : NSObject <Child> {
> id <TProtocol> inProtocol;
> id <TProtocol> outProtocol;
> }
> - (id) initWithProtocol: (id <TProtocol>) protocol;
> - (id) initWithInProtocol: (id <TProtocol>) inProtocol outProtocol: (id
> <TProtocol>) outProtocol;
> @end
> {noformat}
> With these definitions, an instance of "Child" knows nothing of nor can ever
> have superclass method {{name()}} called on it. This completely breaks not
> only polymorphism, but the use of the "extends" keyword when generating Cocoa.
> This could be easily resolved by simply having the "Child" class also conform
> to the "Parent" protocol, or more-correctly resolved by making "Child" an
> actual subclass of "Parent".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
