Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Fengyang Wang
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.

On Wednesday, September 21, 2016 at 4:48:21 PM UTC-4, Páll Haraldsson wrote:
>
> 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.
>
>

Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Páll Haraldsson
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.



Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Randy Zwitch
OH! That makes a big difference in usability. :)

On Wednesday, September 21, 2016 at 12:50:26 PM UTC-4, Fengyang Wang wrote:
>
> 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.
>
> On Wednesday, September 21, 2016 at 9:59:21 AM UTC-4, Randy Zwitch wrote:
>>
>> 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.
>>  
>> On Wednesday, September 21, 2016 at 9:49:44 AM UTC-4, Yichao Yu wrote:
>>>
>>> On Sep 21, 2016 9:42 AM, "Randy Zwitch"  
>>> 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.
>>>
>>> >
>>> > @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
>>>
>>

Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Fengyang Wang
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.

On Wednesday, September 21, 2016 at 9:59:21 AM UTC-4, Randy Zwitch wrote:
>
> 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.
>  
> On Wednesday, September 21, 2016 at 9:49:44 AM UTC-4, Yichao Yu wrote:
>>
>> On Sep 21, 2016 9:42 AM, "Randy Zwitch"  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.
>>
>> >
>> > @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
>>
>

Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Randy Zwitch
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.
 
On Wednesday, September 21, 2016 at 9:49:44 AM UTC-4, Yichao Yu wrote:
>
> On Sep 21, 2016 9:42 AM, "Randy Zwitch"  > 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.
>
> >
> > @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
>


Re: [julia-users] Understanding Nullable as immutable

2016-09-21 Thread Yichao Yu
On Sep 21, 2016 9:42 AM, "Randy Zwitch"  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.

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