On Oct 10, 2013, at 11:17 AM, Joseph Rushton Wakeling <[email protected]> wrote:
> On 10/10/13 19:50, Sean Kelly wrote: >> Configuration data, for example. On app start you might load a config file, >> generate information about the user, and so on, before real processing >> begins. This data needs to be visible everywhere and it rarely if ever >> changes as the program runs, so you fill the data structures and then make >> them immutable. Assuming, of course, that the data structures have >> immutable versions of all the necessary functions (which is unfortunately a >> pretty big assumption). > > Yup, you're right, it's a big assumption. In my case I was interested in > loading a graph (network) and running many simulations on it in parallel. > The graph itself was static, so could readily be made immutable. However, I > found that it was difficult to write code that would accept both immutable > and mutable graphs as input, without impacting performance. So, I opted for > threads to receive an immutable graph and cast it to mutable, even though it > was never actually altered. > > My experience was no doubt partially due to issues with the overall design I > chose, and maybe I could have found a way around it, but it just seemed > easier to use this flawed approach than to re-work everything. That's kind of the issue I ran into with shared in Druntime. It seemed like what I had to do was have a shared method that internally cast "this" to unshared and then called the real function, which I knew was safe but the type system hated. But this seemed like a horrible approach and so I didn't ever qualify anything as shared.
