Re: How to convert String.Index to UInt?
Re: How to convert String.Index to UInt?
- Subject: Re: How to convert String.Index to UInt?
- From: Quincey Morris <email@hidden>
- Date: Sun, 17 Aug 2014 22:44:30 -0700
On Aug 17, 2014, at 21:36 , Gerriet M. Denkmann <email@hidden> wrote:
> Step 1 is to learn how to convert things one does in Obj-C into Swift.
> Step 2 would be to think in Swift and do things in a swifty way.
>
> And you are right: I am currently at Step 1, and am far away from having mastered it.
Watching (so to speak) what you’re doing from a distance, what concerns me is *not* that you are or are not doing things in a swifty way, but that you’re *evaluating* Swift when it’s still in an incomplete form — unstable, under-documented, and under-implemented. I know you’ve said you’re “just” trying to learn the new language at this point, but I think there’s a danger that you’ll conclude that the new language is unusable (or incomprehensible, or something) *because of* its current incomplete form.
> But what worries me more are limitations in Swift:
See what I mean? It may be necessary to simply suspend judgement (and worry) until later.
> Obj-C was always praised for it's dynamic nature, which - so the argument went - lets you do things which are (nearly) impossible in other languages.
>
> Swift has NSSelectorFromString, but one can do nothing with this Selector (except passing it to some Obj-C object).
> The Book says: “The performSelector: method and related selector-invoking methods are not imported in Swift because they are inherently unsafe.”
This particular issue isn’t Swift-related, but ARC-related.
The value of ARC is that it preserves correctness (memory-management correctness, I mean) in source code that follows the ARC rules. Within the ARC domain — that is, if you write code according to the rules — you *cannot* have any memory management errors**. But you only get this happy outcome if you stay within the ARC domain. If you invoke code that doesn’t use ARC, or that ARC tells you is unsafe, then there is no guarantee of correctness. (Of course, your app may turn out to be correct if this non-ARC-domain code has no memory management bugs, but the correctness then comes from something outside of ARC’s purview.)
The problem with ‘performSelector:’ is that it can break out of the ARC domain. Even if the invoking code uses ARC, and the performed code uses ARC, the transition between them isn’t necessarily correctness-preserving.
There’s no practical possibility of eliminating ‘performSelector:’ from Obj-C, but Swift simply decided not to import the problem, by not implementing the ‘performSelector:’ mechanism. The alternative mechanism — for both Obj-C and Swift environments — is, of course, closures/blocks.
Unfortunately, it’s harder to convert from ‘performSelector:’ and Obj-C to closures and Swift simultaneously, than it is to convert them sequentially.
** Barring bugs in the compiler itself, or bugs in your code that clobber pointers in memory.
_______________________________________________
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