On Sep 6, 2015, at 10:25 , has <hengist.p...@virgin.net> wrote: > > Each of those intermediates describes a valid query in itself; you just keep > chaining var/method calls until you build up the query you actually want.
Yes, that’s what I thought. I was trying to say that from an API perspective, it’s not necessary that the specifier objects (the predicates, so to speak) are the same objects as the IPC managers (the queries). It’s just that combining both behaviors into the same object is an economy of scale, since there are so many customized classes involved. Similarly, the question of creating brand new objects isn’t really significant to your API. It’s more of a policy decision that simplifies other implementation details. But … > I'm getting that sinking Radar feeling too. But since I'm relatively new to > Swift, I'm just holding out a vain hope that there's some sort of solution > that's embarrassingly obvious to everyone else but me. I’ve been thinking about the implications of this for a couple of days now. Of course, you should file a Radar if you see some compiler behavior that looks like it ought to work. But I think there’s a higher order problem that’s worth noting. In my experience (which is to say, after a couple of months spent converting a fair-sized app from Obj-C to Swift), converting an Obj-C implementation to directly an “equivalent” Swift implementation is a lousy experience with poor results. There are several waves of consequences from the attempt: 1. You struggle to find a Swift equivalent of your Obj-C code. It takes forever. 2. You find your equivalent code ends up wordier and somehow more "unfactored" than the Obj-C code, even though it is somehow “the same”. You hate using it. 3. You fiddle with the Swift implementation (leaving Obj-C behind, finally) to make it a bit more streamlined. It takes forever. 4. You crash the compiler AND SourceKit, because you’ve ventured into uncharted territory in order to hide an Obj-C-derived mess behind Swift syntax. You have to look for workarounds at least until the next Xcode beta. You seem to be in the process of trying to produce a Swift equivalent of your existing Obj-C implementation. You even state your abstract problems (how to arrange vendor methods in ObjectSpecifiers, for example) in Obj-C terms — as a subclassing problem, rather than a behavioral problem, which in Swift will tend to lead you first in the direction of protocols rather than subclasses. (But merely defining a protocol for each of your subclasses is not an improvement here.) So, here’s what I suggest: — Avoid the temptation to over-generalize in Swift. Capabilities like generics, overloading and even protocols (protocol extensions) seem to offer a magical veil to hide complexity. They don’t. — Start with simple, straightforward solutions to your class APIs. Need three return types? Write three different methods. — Write code that uses your class APIs as early as possible. (I’m talking about a small cluster of related classes, typically, not all the classes in the app.) Note what hurts to use, what’s too ugly, and what’s too verbose. — Throw away your APIs and redesign them to be pleasant to use. Repeat this step as often as necessary. — Use what feels natural in Swift, and take the time to experiment until you find it. Leave Obj-C behind. Admittedly, I’ve retreated from your original topic to a matter of philosophy. Feel free to ignore the opinion if it doesn’t work for you, but again I assure you I speak from painful experience. _______________________________________________ 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
