Groups   90 of 99+      julia-users › Understanding Nullable as immutable 7 posts by 4 authors      Randy Zwitch    Sep 21   I frequently have a design pattern of Union Title, Void . I was thinking that I could redefine this as title::Nullable Title . However, once I try to modify fields inside the Title type using setfield! ec.title, k, v , I get this error message:  LoadError: type Nullable is immutable while loading In 19 , in expression starting on line 4   My question is, why is the Nullable type immutable? My original thought was that my Nullable definition was saying  There is either a Title type here or nothing missing , and maybe I know the value now or maybe I know it later. But it seems the definition is actually  There could be a Title type here or missing, and whatever you see first is what you will always have   Is there a better way to express the former behavior other than as a Union type? My use case is building JSON strings as specifications of graphs for JavaScript libraries, so nearly every field of every type is possibly missing for any given specification.   with_kw type EChart  : AbstractEChartType       title::Union Title,Void    Title       title::Nullable Title    Title       legend::Union Legend,Void    nothing     grid::Union Grid,Void    nothing     xAxis::Union Array Axis,1 ,Void    nothing     yAxis::Union Array Axis,1 ,Void    nothing     polar::Union Polar,Void    nothing     radiusAxis::Union RadiusAxis,Void    nothing     angleAxis::Union AngleAxis,Void    nothing     radar::Union Radar,Void    nothing     dataZoom::Union DataZoom,Void    nothing     visualMap::Union VisualMap,Void    nothing     tooltip::Union Tooltip,Void    nothing     toolbox::Union Toolbox,Void    Toolbox       geo::Union Geo,Void    nothing     parallel::Union Parallel,Void    nothing     parallelAxis::Union ParallelAxis,Void    nothing     timeline::Union Timeline,Void    nothing     series::Union Array Series,1 ,Void    nothing     color::Union AbstractVector,Void    nothing     backgroundColor::Union String,Void    nothing     textStyle::Union TextStyle,Void    nothing     animation::Union Bool,Void    nothing     animationDuration::Union Int,Void    nothing     animationEasing::Union String,Void    nothing     animationDelay::Union Int,Void    nothing     animationDurationUpdate::Union Int,Void    nothing     animationEasingUpdate::Union String,Void    nothing     animationDelayUpdate::Union Int,Void    nothing end     Yichao Yu    Sep 21   On Sep 21, 2016 9:42 AM,  Randy Zwitch   randy.... fuqua.duke.edu  wrote:     I frequently have a design pattern of Union Title, Void . I was thinking that I could redefine this as title::Nullable Title . However, once I try to modify fields inside the Title type using setfield! ec.title, k, v , I get this error message:     LoadError: type Nullable is immutable while loading In 19 , in expression starting on line 4         My question is, why is the Nullable type immutable? My original thought was that my Nullable definition was saying  There is either a Title type here or nothing missing , and maybe I know the value now or maybe I know it later. But it seems the definition is actually  There could be a Title type here or missing, and whatever you see first is what you will always have      Is there a better way to express the former behavior other than as a Union type? My use case is building JSON strings as specifications of graphs for JavaScript libraries, so nearly every field of every type is possibly missing for any given specification.  Assign the whole object instead of mutating it.       Randy Zwitch    Sep 21   So get   to check if a value is there, and if there is modify a copy then overwrite?  If that's the case, it might be worth the mental overhead to use Nullable types when mentally I'm viewing everything as a consistently mutating object until the desired result is achieved.      Fengyang Wang    Sep 21   There is no need to modify a copy; only the Nullable is immutable and not its underlying value. Just instead of modifying ec.title, modify get ec.title . Like setfield! get ec.title , k, v . In short scripts, I often define getindex x::Nullable    get x  so that I can write ec.title   instead of get ec.title , but type piracy is bad practice. This method should really be in Base.      Randy Zwitch    Sep 21   OH! That makes a big difference in usability. :       Páll Haraldsson    Sep 21   On Wednesday, September 21, 2016 at 4:50:26 PM UTC, Fengyang Wang wrote: but type piracy is bad practice. This method should really be in Base.  As always, if something, should be in Base or Julia, then I think a PR is welcome.   Maybe I do not fully understand this  yes, type piracy I guess equals, accessing internal variable, that would be Private  to not violate Parnas' Principles  in other languages .  I like how Julia avoids Hoare's self-admitted billion dollar mistake. It seems to violate Parnas' but since no type can subtype a concrete type, it may not, or at least that violation can always be avoided ? .   --  Palli.      Fengyang Wang    Sep 21   Yes, I've been meaning to submit a PR. The last one contained several other changes which were substantially more controversial. My plan was to split the PR up into smaller changes.