On 08/09/2015 16:38, Charles Srstka wrote:
On Sep 8, 2015, at 4:18 AM, has <hengist.p...@virgin.net
<mailto:hengist.p...@virgin.net>> wrote:
But after adding a protocol to supply this information, SourceKit and
swiftc crash upon reading the code:[...]
That’s true; however, adding a second “YourObjectProt" protocol,
making YourObject conform to it, adding all of YourObject’s methods
into the protocol, and using YourObjectProt as the parameter instead
of YourObject, will solve the issue.
(Bear in mind the goal is for the glue to declare the correct return
types on the library class's methods. Your previous example passed a
protocol to the generic BaseObject class, but your foo/bar/baz functions
never used it as they don't return anything.)
Ok, so trying this:
class ObjectBase<T> {
required init() {}
func foo() -> T.FooType { return T.FooType.init() }
}
protocol MyProtocol {
typealias FooType
func foo() -> FooType
}
class MyObject: ObjectBase<MyProtocol>, MyProtocol {
typealias FooType = MyObject
required init() {}
}
let obj = MyObject()
I get a compiler error on the foo function's return type: 'FooType' is
not a member type of 'T'. Probably just wishful thinking, that one, so
let's not dwell on it.
Next, trying to move the base functions into a protocol extension (which
use typealiases instead of generics):
protocol Init {
init()
}
protocol BaseProtocol {
typealias FooType: Init
func foo() -> FooType
}
extension BaseProtocol {
func foo() -> FooType { return FooType() }
}
class MyObject: BaseProtocol {
typealias FooType = MyObject
required init() {}
}
let obj = MyObject()
Code looks promising, but the compiler complains "Type 'MyObject' does
not conform to protocol 'BaseProtocol'." Nuts. Any ideas? Have I just
missed something obvious?
Swift wants you to use protocols rather than objects anyway, so
perhaps the way to go is to put all the logic in the protocols and
protocol extensions, and make MyObject, YourObject, etc, just
bare-bones objects (or structs) that just belong to the protocol and
don’t do anything else.
Yeah, the goal is for each app-specific glue to subclass the concrete
library classes (which provide the query-building and AE dispatch
services using raw four-char codes, and already work nicely in
themselves), then use protocol extensions to add the app-specific
vars/funcs into those. So I don't have a problem with mixing-in the base
functionality as well; just wish swiftc felt the same way as well. :p
Thanks,
has
_______________________________________________
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
