Should I be using more catchless do blocks?


(Michael Savich) #1

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


(Michael Ilseman) #2

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


(Rien) #3

Yes.

But: Only if it makes the code better.

I think that “understandability engineering” is just as important as “software engineering”. Maybe more so. After all, code that we understand has a better chance of working correctly than code that follows all paradigms but once the developer is gone nobody is able to maintain.

I.e. worry less about idiomatic programming and write more understandable code.

Swift is getting - well maybe it’s past already - the point where an experienced programmer can write code that no newbie has even a chance of understanding. If code blocks help in breaking this trend, go for it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift

···

On 19 Jun 2017, at 04:07, 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


(Michael Savich) #4

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. 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.

Anyway, do you think that most Swift users are even aware that do can be used in this fashion?

···

Sent from my iPad

On Jun 19, 2017, at 2:33 PM, Michael Ilseman <milseman@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


(Michael Ilseman) #5

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.

···

On Jun 19, 2017, at 11:47 AM, Michael Savich <savichmichael@icloud.com> wrote:

Sent from my iPad

On Jun 19, 2017, at 2:33 PM, Michael Ilseman <milseman@apple.com <mailto:milseman@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 <mailto: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 <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users


(Geordie J) #6

Sorry in advance if Google Inbox messes with my code formatting below
(can't there be just one good email client? I miss Mailbox)

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.

In my experience, the most idiomatic and readable (and testable! if that's
important in your context) way of doing this is to create extensions to
group and encapsulate related functionality (example obviously won't
compile but hopefully you get what I mean):

extension MyViewController {
    override public func viewDidLoad() {
        let something = processModelData(data)
        let views = something.map { UIView($0) }
        addRelatedSubviews(view)
    }

    private func addRelatedSubviews() {...}
    private func processModelData() {...}
}

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.

Anyway, do you think that most Swift users are even aware that do can be
used in this fashion?

Yes, and sometimes it's useful, most of the time I've seen or used it
myself I'd consider it a code smell.

This is just a personal preference but I find that more indentation is
almost always harder to read than less. The aim is to reduce cognitive load
("Don't make me think").

···

Michael Savich via swift-users <swift-users@swift.org> schrieb am Mo. 19. Juni 2017 um 20:54:

Sent from my iPad

On Jun 19, 2017, at 2:33 PM, Michael Ilseman <milseman@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


(Michael Savich) #7

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 <milseman@apple.com> wrote:

On Jun 19, 2017, at 11:47 AM, Michael Savich <savichmichael@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 <milseman@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