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.

- show quoted text -
 


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.
- show quoted text -
 


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.
- show quoted text -
 


Randy Zwitch 	

Sep 21


OH! That makes a big difference in usability. :)
- show quoted text -
 


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.
- show quoted text -