1 - i asked myself the same question after posting and went back and looked at the use case that motivated this. and it was for values that i need to mutate early in their lifetime, and which then remain invariant. i've been thinking about how i could have done it differently, and one approach i am considering is re-creating the objects during the start-up process. i think that would work. so that particular use case is perhaps not so convincing.
2 - however, isn't there still a case for things that should be semantically equal, even though they are composite? maybe i am misunderstanding how things work, but i could imagine some object that stored, say, name and age. if i used an immutable type then equality would depend on interning of strings, wouldn't it? another example would be immutable arrays. in short: immutable things that are accessed by a pointer, and whose contents you want to include in equality. andrew On Sunday, 19 July 2015 11:53:43 UTC-3, Stefan Karpinski wrote: > > I don't really get what's lacking. If you want an immutable record type > why not just use an immutable type? > > On Jul 19, 2015, at 8:03 AM, andrew cooke <and...@acooke.org <javascript:>> > wrote: > > > you may be interested in https://github.com/andrewcooke/AutoHashEquals.jl, > but it uses all entries. i will consider adding that feature, though (with > the idea that if it's not used at all, all are used). > > more generally - and this may just be a problem with my programming style > - i find that there's a problem with julia (or me) conflating two different > things: > > * record types > * immutable types > > immutable types in julia are intended, as far as i can see, for small, > value-like things that are stored on the stack. while "types" are for > larger, record like things. > > some of us (perhaps coming more from a functional programming background) > like to program with records that are immutable, we have no way to do that > in julia except by convention. > > hence the need for AutoHashEquals (imho) (there are two problems - first, > most obviously, you then want record equality to depend on contents, but > second, less obviously, when these "immutable records" are used in > immutable types then you want the immutable type's hash to depend on the > record's contents, and not on the pointer value. hence applying the macro > to both types). > > andrew > > > On Friday, 17 July 2015 12:52:52 UTC-3, Seth wrote: >> >> Perhaps a @unique macro in front of the type field could specify that >> this is to be used in equality/hashing? >> >>
