Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Converting a data type to an abstract data type (Ryan Warner)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Sep 2015 17:02:03 +0000
From: Ryan Warner <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Converting a data type to an abstract
data type
Message-ID:
<CAMV_cL3bamaOM51=hsx5k+suvoaelhwnixxtgwjxmopfxro...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Sep 14, 2015 at 10:17 PM Kim-Ee Yeoh <[email protected]> wrote:
>
> On Tue, Sep 15, 2015 at 1:23 AM, Ryan Warner <
> [email protected]> 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150915/de673f10/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 87, Issue 7
****************************************
