So, this actually modifies an immutable, right? This doesn't seem right, aren't they supposed to be immutable?
On Mon, 2015-02-09 at 14:29, Simon Danisch <[email protected]> wrote: > You can actually modify immutables in an array directly. I actually > implemented this in GLAbstraction for my own usage. > I'm implementing FixedSizeArrays.jl > <https://github.com/SimonDanisch/FixedSizeArrays.jl> at the moment, which > will include this feature (In the feature list I call > it "setindex!/getindex for arrays of FSA (e.g. easy access to single > fields)") > This only works for immutables as it needs the tightly packed memory layout > of the array... Sadly, immutability doesn't occur in the type hierarchy, so > the setindex! that I'm talking about can't be written to work for any > immutable. > So this means, you either need to inherit from FixedSizeArrays to use this, > or copy the code (when it's transfered to fixedsizearrays). > Maybe we can open an issue at Julia, to see if we can get something like > this into base. > > Am Sonntag, 8. Februar 2015 21:35:20 UTC+1 schrieb [email protected]: >> >> I would like to request the following language feature: a function or >> macro to modify a field of an immutable inside a container. Consider: >> >> immutable T >> fielda::Int >> fieldb::Int >> fieldc::Int >> end >> >> function modify_fieldc!(x::Array{T,1}, sub::Int, newc::Int) >> x[sub] = T(x[sub].fielda, x[sub].fieldb, newc) >> end >> >> This function modifies one field of an immutable object that sits inside a >> container. The above construct, namely: >> x[sub] = T(x[sub].field1, x[sub].field2, ... , newval, ... >> x[sub].fieldn) >> occurs rather frequently in my code. It is not very readable and is also >> fragile in the case that I modify my code and put more fields in T later. >> It would be much nicer if there were a universal function like this: >> modifyField!(x, sub, fieldc, newc) >> >> Note that I declared T to be 'immutable' rather than 'type' for >> performance reasons-- I prefer the data in the array x to be packed in >> memory rather than accessed with pointers. If T were a 'type' then >> obviously the problem would go away. >> >> Maybe it is already possible to write a function or macro for this purpose >> in the existing language? >> >> Thanks, >> Steve Vavasis >> >>
