FWIW, I find that using "my" as a prefix is handy to specify a local, as it is a brief visual notification that the variable is a local just by eyeballing it. Sometimes it adds greater clarity.
Just my 2 cents, Cheers. Sent from my iPad. Please pardon typos. On Mar 4, 2015, at 2:48 PM, Fritz Anderson <[email protected]> wrote: > On 2 Mar 2015, at 1:21 PM, Mutlu Qwerty <[email protected]> wrote: > >> Here is what I have tried, what is the correct way to code this block? >> >> var counter: Int = 0 >> let myRecID: NSString = "00722371-b24d-421f-99c6-63d06226253e" >> var myCKRecordID: CKRecordID! = CKRecordID(recordName: myRecID) >> let myCKRecordIDArray: [CKRecordID!] = [myCKRecordID] >> var myCKFetchRecordsOperation: CKFetchRecordsOperation = >> CKFetchRecordsOperation(recordIDs: myCKRecordIDArray) >> >> var myProgress: Double = 0.0 >> myCKFetchRecordsOperation.perRecordProgressBlock( { (myCKRecordID, >> myProgress) -> Void in >> print("At perRecordProgressBlock ") >> print(counter++) >> print(" ") >> println(myProgress) >> })//end of block >> > > I don’t have an active CloudKit entitlement, so I can’t test this, but I have > some observations. > > First and most important: > > In what way does what you are doing prove to be incorrect? Fails to compile, > runtime error, no error but unexpected results, block never entered? > > -- > > Passing observations: > > Most of the type declarations for your vars and lets are unnecessary. Swift > will do better than you can (barring bugs in the compiler) at using the > values you assign to the symbols to infer the types. That may force you to do > coercions later, but having to do explicit coercions at the places they are > needed shows the reader — and you — something about the design and effect of > your code. > > -- > > It appears you expect the closure parameters myCKRecordID and myProgress to > be the same as the vars of those names in the func that contains the call to > perRecordProgressBlock. They aren’t. They’re parameter names that you’ve made > identical to those of vars you use elsewhere. > > If you had a func that had vars a and b, and it called an outside func that > has the signature > > func aFunc(a: String, b: Int) > > you would not expect aFunc’s a and b parameters to be the same variables as > the a and b in the function that called it. Same thing. > > Given that the perRecordProgressBlock closure is within the scope of the > block that declares counter, and the closure doesn’t redefine the symbol, you > have counter right. > > -- > > If it were me, I’d write the perRecordProgressBlock call thus: > > myCKFetchRecordsOperation.perRecordProgressBlock { > _, cloudKit_sProgress in > println("At perRecordProgressBlock \(counter++) \(cloudKit_sProgress)") > } > > In other words, let the language do your work for you, don’t bother to name > things you won’t use (in your real code, I assume you’d have to replace _ > with cloudKit_sRecordID), and don’t confuse the reader by giving the same > name to two different objects. > > -- > > I assume you don’t use the “my” prefix as liberally as this in your real > code. The reader sees that the symbols are defined right there. She can do > the math about their being yours. It’s distracting. > > -- > > These things may or may not solve your problem — you haven’t really said what > your problem is. > > — F > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Xcode-users mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/xcode-users/zav%40mac.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
