Many things dont get mutated in higher level programming ..to name a few. - Objects Read data from DB in many application , many DBs are 90% read. As there is no benefit in Java /C# most implimentations have these as mutable but you could use seperate objects for read and mutate. ( CQRS really shows this ) - Read only collections / CADR lists - Formatted/ Deserialized event messages and commands. eg stock price changed events. Post data - Many constructor dependency injected objects . - XML / HTML DOM structures could be created immutable. ( Most are only mutable at init but its not the constructor) . - Simple objects like Matrixes and Points (in Java they are not objects in C#/ Bitc)
Strings will be the majority . I think a frozen bit in the header would pay of ( eg DB read objects ) . Maybe you can do more. At any time nearly all objects can not change as the current code does not change them . If you say all non global objects default to immutable . Then users have to explicitly state which params will have mutable data eg rw keyword . This then clears the bit on the object ( a cost but it will be written to anyway so a "prefetch" ). This would have 2 issues - re deep immutability when you go to a.b = the compiler needs to put this in a seperate function though likely it will be inlined with setting the header included . ( in which case you may not even need the explicit rw) - Its on the "hot path" so some sort of analysis would be needed to only set the object once prehaps for its whole life. - maybe hot objects can be marked always mutable ignoring the refault ro ( or for programers who dont care about performance though there are maintenance advanatges to ro) I dont think the pay off will cover the costs but it may , there are many other benefits to knowing objects will not changes. Ben On Thu, Oct 17, 2013 at 9:16 AM, Jonathan S. Shapiro <[email protected]>wrote: > I suspect it's almost entirely due to string data, and almost everything > else gets mutated. > > The main reason it's of interest is that forwarding a frozen object is > very easy; you don't care which version the client code operates on, > because neither is changing, so you don't need a barrier. > > What I'm really wondering here is whether a "frozen" bit in the object > header would have much payoff. I suspect that with additional source > language emphasis on immutability it might. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
