Good points. Given that symbols have a name which is a string, I don't see how they could be a bits-type unless they just became numbers to index into a global array somewhere...... i.e. a pointer. Stack-allocating non-bits-type immutables is on the roadmap to 1.0, so that should solve your problems.
Maybe you can solve the CategorizedPoint problem by using an @enum. On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz <[email protected] > wrote: > Hello Andreas, > > consider iterating over a Dict{Symbol,Int64}: > > d = Dict(:foo => 42, :bar => 77) > for x in d println("$(typeof(x)), $(isbits(x))") end > > > During iteration, a lot of stack allocated "Pair{Symbol,Int64}" objects > are created. That is very bad for performance. > > immutable CategorizedPoint > x::Float64 > y::Float64 > category::Symbol > end > > > Also, consider a (hypothetical) data type for categorized points (with a > finite number of categories - but extensible, so that Symbol is a better > fit than using an enum): > > immutable CategorizedPoint > x::Float64 > y::Float64 > category::Symbol > end > > I would definitely want this to be a bits-type, and not have every > instance heap-allocated. > > > Cheers, > > Oliver > > > On Wednesday, August 17, 2016 at 11:44:13 AM UTC+2, Andreas Lobinger wrote: >> >> Hello colleague, >> >> On Wednesday, August 17, 2016 at 11:12:51 AM UTC+2, Oliver Schulz wrote: >>> >>> Sure - I was assuming that as Symbol (as an interned string) is >>> basically just a pointer. So comparisons are O(1), etc. What I'd like to >>> understand is, why can't it be a bitstype? Currently, it's not, so Symbol >>> cannot be used in a lightweight (i.e. stack-allocated) immutable type. I >>> assume there's a good reason for it, I just want to understand why. >>> >> >> Could you make an example how you would like to use Symbol in lightweight >> types? >> >>
