Huh, I didn't realize you could nest functions like that. That being said, I'm not sure the declare-then-use structure really appeals to me personally. I might use it if the function was getting really long.
One last question: labels on do blocks. I know they are mostly intended to be used for that goto-lite behavior, but are labels also meant to be used by themselves, to describe the code they lead into? I never understood if they were meant to be used that way in C either… Sent from my iPad > On Jun 19, 2017, at 6:51 PM, Michael Ilseman <milse...@apple.com> wrote: > > >> On Jun 19, 2017, at 11:47 AM, Michael Savich <savichmich...@icloud.com> >> wrote: >> >> Yeah, it's all about balance to be sure. Though one benefit of do blocks is >> in functions that are tied to a sense of time. It seems to me that the in >> case of something like viewDidLoad separating code into too many functions >> can obscure the fact that the code is meant to be executed at that time. > > I was referring to defining a local function inside your function that you’re > refactoring. As in, rather than say: > > func foo(...) -> … { > // some initialization > do { > … some local variables, some not local... > } > > code1... > > // some more scoped work > do { > … some local variables, some not local... > } > > code2... > > // some finalization > do { > … some local variables, some not local... > } > } > > You have: > > func foo(…) -> … { > func doLocalSetup(…inputs...) { > … use explicit inputs and local variables > } > func performScopedWork(…inputs…) { > … use explicit inputs and local variables > } > func doFinalTearDown(…inputs…) { > … use explicit inputs and local variables > } > > doLocalSetup(…) > defer { doFinalTearDown(…) } > > code1... > > performScopedWork(…) > > code2... > } > > > That’s just one option. You also mentioned using closures, which can be less > clear if you’re relying on implicit captures rather than explicit parameters > (which can have labels/names). It all depends on the details. > >> Closures can provide much of the same functionality but I'm pretty sure >> inline closures have to have names and sometimes risking a bad name is worse >> than no name at all. >> > > That might be the case. However, often such a do block is worthy of a comment > before it, and good names make really good comments. > >> Anyway, do you think that most Swift users are even aware that do can be >> used in this fashion? >> > > I wouldn’t think it would be obvious to new Swift programmers, but might be > familiar to programmers coming from other languages that use scopes heavily. > > It probably depends on your team specifics. As you mentioned, you only > recently learned of this behavior, so your experience might be a useful proxy > for whether others are or are not familiar. > >> Sent from my iPad >> >>> On Jun 19, 2017, at 2:33 PM, Michael Ilseman <milse...@apple.com> wrote: >>> >>> Introducing scope to manage lifetimes of local variables is a useful and >>> valuable practice. Note that it might also be an opportunity to refactor >>> the code. Any do block you want to introduce could also be a local function >>> definition that you call later. Alternatively, it could be generalized and >>> extracted into a utility component. Long function bodies with many do >>> blocks could be a code smell. >>> >>> >>>> On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users >>>> <swift-users@swift.org> wrote: >>>> >>>> So, something I did not know until recently is that do blocks in Swift are >>>> for more than just error handling, they can also be used to tighten scope. >>>> >>>> I'm wondering, why not use a ton of do blocks? Like, if I have a >>>> ViewController lifecycle method like viewDidLoad, I could segment it into >>>> out a do block for creating subviews, a do block for loading data into >>>> them, and a do block for adding them to the view itself. This seems like >>>> it would enforce grouping code tightly together. >>>> >>>> Yes I could adopt a functional style of programming, but that has its >>>> downsides too, namely reading any functional code involves trawling >>>> through a long sequence of function calls. What I'm saying is, do blocks >>>> seem like a way to get many of the benefits of functional programming >>>> while maintaining the readability of imperative code. (Sorry functional >>>> programmers, I promise I love Haskell too!) >>>> >>>> So I guess what I'm saying is… somebody talk me down from this ledge. Is >>>> there a reason I shouldn't refactor my projects to be full of do blocks? >>>> And can this usage of do really be considered idiomatic Swift? Or will >>>> most people reading my code be left wondering where all the try and catch >>>> statements are? >>>> >>>> Sent from my iPad >>>> _______________________________________________ >>>> swift-users mailing list >>>> swift-users@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-users >>> >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users