Re: [swift-users] Should I be using more catchless do blocks?

[Geordie Jay via swift-users]

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

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

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


>
> Sent from my iPad
>
> On Jun 19, 2017, at 2:33 PM, Michael Ilseman  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
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Should I be using more catchless do blocks?

[Rien via swift-users]

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

Re: [swift-users] Should I be using more catchless do blocks?

[Michael Savich via swift-users]

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

Re: [swift-users] Should I be using more catchless do blocks?

[Michael Ilseman via swift-users]

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

Re: [swift-users] Should I be using more catchless do blocks?

[Michael Ilseman via swift-users]

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

[swift-users] Should I be using more catchless do blocks?

[Michael Savich via swift-users]

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