On Sep 3, 2015, at 11:16 , has <hengist.p...@virgin.net> wrote: > >> * 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.
Huh? Why is it fine to create an additional unnecessary object? And what has this got to do with Apple events? The problem with using an instance of the class as a factory is that by the time you’ve built the factory (instantiated the factory instance), you’re already done building the object you really wanted — you wanted an instance and you have it. > 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() Again: huh? Where’s the factory method in this? In Obj-C, it is more or less viable to follow the factory-instance strategy. That’s because (a) Obj-C separates alloc from init, so you alloc an instance (a small waste of time) and then throw it away without going through a full init (which could be a large waste of time or have side effects); and (b) you’re allowed to bail out of init early (though it depends on multiple factors whether it’s actually safe to do so). This situation doesn’t exist in Swift. You must initialize every object fully, and that includes a factory-instance. Because of that, you may as well (and ought to) use a class-level factory method instead. _______________________________________________ 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
