This seems like a reasonable change to make, though I'd like to talk it out a
bit further before we go ahead with it. It will obviously help reduce developer
error, and the stack semantics you described below will reduce heap
allocations, which is nice. Are there other advantages? What are the drawbacks?
On Thursday, April 09, 2009, at 05:02PM, "Noel Grandin" <[email protected]>
wrote:
>Hi
>
>Starting a new discussion thread...
>This question is interesting to me because it's one of those questions
>that has to be answered early on in the life of a project before the
>mass of accumulated code becomes so heavy that it can't be changed.
>
>>>(*) Should pivot.wtk.Dimensions/Insets/CornerRadii/Bounds be final and
>>>immutable?
>>
>> This is a very good question, and could definitely generate a lot of
>> discussion. Ideally, they would be implemented as structs, but Java doesn't
>> have structs.
>
>With the escape analysis that was introduced in the 1.6 VM, a class like
> public final class Point {
> public final int x;
> public final int y;
> }
>should, in theory, be transformed into a purely stack- or
>register-allocated object.
>
>Now, from experience, the current 1.6u10 VM doesn't seem to be doing a
>great job of escape analysis.
>
>But judging from the academic papers available and the direction the
>VM engineers are moving in, I think this is only going to improve.
>
>So then, the question becomes
>(a) is the coding style appealing (I think it is)
>(b) is the performance cost in deploying to current VMs worth the
>future benefit (don't know the answer to this one)
>
>Regards, Noel.
>
>
