Re: ignorance: customizable immutables?

On Saturday, June 20, 2015 at 6:32:21 AM UTC+8, Andrew Phillips wrote:
>
> List(new A, new A{ override def foo = "different" })
>
>  
>
> Are there any approaches people like to use to get immutables that 
> respect whatever customization has been done -- some way to assemble 
> components and then still be able to frob() them and get a new 
> immutable copy that retains the customizations?
>
>
> I'm probably missing something here, but it seems to me that the example 
> given depends mainly on the fact that the customization is in an anonymous 
> subclass? If instead you had:
>
> class AStar extends A {
>   override def foo = "different"
> }
> List(new A, new AStar)
>
>
The operation subsumes to the type A, so a new type of A is constructed not 
AStar. 

> then - assuming a suitably implemented clone method on AStar - wouldn't 
> you retain the special foo behaviour even if new instances are created? Or 
> is the creation of *anonymous* subclasses central to your scheme?
>
> Regards
>
> ap
>
> On Tuesday, June 16, 2015 at 1:44:58 PM UTC-4, raould wrote:
>>
>> >   List(new A, new A{ override def foo = "different" 
>> }).map(x.asCapitalA) 
>> > If `asCapitalA` has mutating side-effects, you retain the distinct 
>> `foo` 
>> > behavior.  If, in contrast, it creates a new immutable A, your unique 
>> `foo` 
>> > behavior is lost. 
>>
>> Are there any approaches people like to use to get immutables that 
>> respect whatever customization has been done -- some way to assemble 
>> components and then still be able to frob() them and get a new 
>> immutable copy that retains the customizations? Concisely, robustly? I 
>> mean in any programming language. 
>>
>

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