On Mon, Sep 14, 2015 at 10:17 PM Kim-Ee Yeoh <ky3@atamo.com> wrote:

On Tue, Sep 15, 2015 at 1:23 AM, Ryan Warner <ryan.warner.mn+haskell@gmail.com> wrote:
However, I see the potential for this to be a bigger job. Are there any editors that automate that kind of refactoring?

Let me ask: for this smaller scenario, what were the repetitive activities? Specifically, how would automation alleviate the labor?

I should've just posted a link. So, this is my toy project I'm using to learn haskell. I changed the definition of my Room datatype, and then that propagated though some other types and functions.

In this case, I decided that including the room's textual description in the model itself felt like the model was being polluted with view information. So I converted the Room to a parameterized datatype to allow me to relocate the textual description.

You can see that here:

https://github.com/LoggerMN/hsAdventure/commit/b19514bd639e7e575151f659851d80ee4f832860#diff-10e71f04a6bef79f976e195d937f0bfbL21

As for the potential for this to be a bigger job, aren't there ways of minimizing such blowup risks in the first place? What can be done to avoid incrementalizing on data design?

I see many ways to improve this code. And to be sure, next time I'll be closer to an ideal answer the first time out of the chute. So, practice and planning will minimize the risk. But that only get's you so far, and a requirement change might require you refactor your code anyway. As you say, it minimizes, does not eliminate the risk.

Other language have powerful refactoring tools, so I was wondering if there were some for haskell as well. Maybe there is a different design pattern I should be using here that would've have avoided this problem. If so, I'd love to know!

-Ryan

-- Kim-Ee

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners