Disqus - Friends of soniccat

Re: Calling Blocks Inline

Karol Kozub — Fri, 28 Feb 2014 10:18:39 -0000

Cool. I didn't know that. This makes the approach even more useful.

Re: Calling Blocks Inline

Karol Kozub — Fri, 28 Feb 2014 12:32:44 -0000

This pattern is intended for use within method bodies, where creating functions isn't possible. To use a function in this context it would have to be defined outside of the method and have all the used local variables as arguments. This approach allows us to avoid such measures when the block is needed in only one place.

Re: Calling Blocks Inline

Karol Kozub — Fri, 28 Feb 2014 13:26:51 -0000

> Yes, I don't see any problem there. Two small methods are better than big one.

Having two methods in place of one is often better, but not always. When the methods are so closely connected that they don't make sense without each other, having the code in two separate places will often just reduce readability.

> Hmm, It's really hard to predict that block will be needed in only one place. Yes, today it's obvious, but what about next week?. Creating a separate method will be nice preparing to code reusing.

Refactoring such blocks into separate methods doesn't seem very difficult, so if they make the code easier to follow, I would postpone any such actions until they prove actually necessary. Also I can imagine situations where you know that the block you're implementing won't be useful in any other context.

Re: MVC Layer Interaction Architecture

Karol Kozub — Thu, 29 May 2014 08:54:32 -0000

Hi. There are a few different possible approaches to errors. You could handle errors internally, use a delegate, create an analogous but separate model event propagation structure, or use the model update structure. We currently use the same structure for both model updates and errors.