Re: Re: ignorance: customizable immutables?

On Fri, Jun 19, 2015 at 10:29 PM, Shelby <[email protected]> wrote:

>
>
> On Saturday, June 20, 2015 at 12:23:12 PM UTC+8, Andrew Phillips wrote:
>>
>> so a new type of A is constructed not AStar.
>>
>>
>> In that case, I probably misunderstood the question. Are we assuming here
>> that there is some kind of generic scheme that returns new immutables,
>> simply based on the inferred type of the instance and the new values?
>>
>
> I assumed that `asCapitalA` meant he was using the functional programming
> style (and not virtual inheritance) where it statically types correctly
> because of the subsumption to List[A].
>

I didn't specify.  But you want it to work whatever the details are.

Andrew's solution does require an unfortunate amount of boilerplate, and
even that's not quite enough for transformations between types to work
properly, so you end up with the CanBuildFrom scheme of the collections
library pretty quickly.

And, while powerful, it is not exactly lightweight syntactically.  And even
_then_ you run into problems (e.g. IndexedSeqView).  Mutation is just
simpler because it separates concerns better--internal state is fiddled
with internally.  You don't have to worry about how to recreate a whole new
object with the updated state.

I guess "mutable data structures encourage and assist separation of
concerns" is pretty close to the inverse of conventional wisdom among those
who favor functional programming, but in _this_ particular case I think
it's true.  (There are of course other cases where it's absolutely not
true.)

  --Rex

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.