My 2c but is sounds like Julia needs a struct keyword which is C packed but 
does not enforce immutability. Immutable should means just that and allows 
the compiler more options for optimization. 

On Monday, February 9, 2015 at 10:22:49 AM UTC-5, Kevin Squire wrote:
>
> Hi Steve,
>
> I have a function in VideoIO.jl which does this: 
> https://github.com/kmsquire/VideoIO.jl/blob/master/src/util.jl#L6-L14
>
> When wrapping libav/ffmpeg libraries, some of the structs have dozens of 
> fields, yet I found that needed to declare them as immutable for C 
> compatibility. At the same time, I needed to modify a few values 
> occasionally.
>
> I have used it without consequences yet, but I don't know that there 
> aren't any.  I would reason that modifying a field of an immutable is 
> equivalent to overwriting the whole thing with mostly the same values, but 
> I'm pretty sure the compiler doesn't recognize that.
>
> Cheers,
>    Kevin
>
> On Sun, Feb 8, 2015 at 12:35 PM, <[email protected] <javascript:>> 
> wrote:
>
>> 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
>>
>>
>

Reply via email to