Re: Swift generics, circular type declarations, and segfaults, oh my!
Re: Swift generics, circular type declarations, and segfaults, oh my!
- Subject: Re: Swift generics, circular type declarations, and segfaults, oh my!
- From: has <email@hidden>
- Date: Thu, 03 Sep 2015 19:16:55 +0100
On 03/09/2015 17:05, Fritz Anderson wrote:
On 3 Sep 2015, at 8:55 AM, has <email@hidden> wrote:
Stuck and looking for ideas here. I need to define a base class whose methods vends instances of its subclasses (thus enabling chained method calls; your basic query builder).
I’m assuming Swift 1.2. The following works in an OS X 10.10 playground:
Swift 2 beta.
class Factory: Printable {
required init() {}
class func makeNew() -> Self {
return self()
}
Urgh. Usually when I try to use Self anywhere, the compiler just whines
at me cos I'm thick and it's unhelpful. But yeah, Self does [annoyingly]
work here, thanks:
func makeNewObject() -> Self {
return self.dynamicType.init()
}
Must've missed it during my experiments. (Ironic when I must've tried
everything else under the sun.) Durr. I shall console myself with the
thought I'm not the only one: SourceKit is falling over in a heap of
infinite recursion [sic] whenever it tries to parse this code. (Will
have to file a bug on that later.)
* Using an instance as a factory for its own class is contrary to general usage, so is a smell at best. It’s a job for a class func.
No, it's fine. It's for an Apple event query builder. Any odd smells are
probably the Apple event architecture's doing.
Chained var/method calls let you build and send AE queries using a
non-atrocious syntax, e.g.:
let result: [String] = try TextEdit().documents[1].text.words.get()
I already prototyped the Swift API using code generation on top of an
existing ObjC API <https://bitbucket.org/hhas/appleeventbridge/> and now
I'm trying to simplify and reimplement the whole thing in pure Swift.
In particular, I want to avoid duplicating base classes' general-purpose
methods in application-specific glues and introduce a little bit of
compile-time rigour, since different types of queries support different
sets of operations (e.g. the compiler shouldn't allow you to ask for a
range of elements on a property specifier, because that's not a valid AE
query form).
So I guess this brings me to my next question: what if I want the base
class methods to instantiate more than one subclass? For example, a
MyObject instance needs to be able to vend instances of both MyObjects
and MyElements, while a MyElements instance needs to be able to do the
same, e.g. much simplified pseudocode:
// standard base class
class ObjectBase<ObjectType, ElementsType> {
func makeObject() -> ObjectType
func makeElements() -> ElementsType
}
// custom glue subclasses
class MyObject: ObjectBase<MyObject, MyElements> {
// adds glue-specific methods
}
class MyElements: MyObject {
// adds additional features only appropriate to elements, e.g.
subscript
}
Needless to say, my only real success here appears to be setting new
records for no. of Swift/SourceKit parse/compile/run crashes per hour.
And that's before I even put constraints on the generic parameters
(since the factory methods refuse to see the subclasses' inits without
them). Ugh. I'm sure set algebra was never this painful in high school...
Many thanks,
has
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden