just to share that with you Begin forwarded message:
From: Daniel Ingalls <Dan.Ingalls@Sun.com> Date: December 24, 2008 8:48:09 PM CEST To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: A little question --- merry christmas
Hi, Stef -
Merry chrismas for you and your family.
and Merry Christmas to you and yours as well!
I have a question for you. What is the reason why method arguments are readonly? Was there an optimisation?
In the context of debugging (which is to say, any time you are looking at the code and thinking about what it does), there is something nicely declarative about having the arguments preserved in the state they were at the time of the call. You can refer to them to see if they make sense, whereas if they have been written over, you cannot do this, and you may not even be able to look in the caller if the value comes from an inline expression. So it affords some of the clarity of the functional programming style. Also, of course, it makes it simpler to implement, and to think about using, the ability of a debugger to restart a method after a change. And finally, if you think about call by reference, overwriting arguments introduces a bit of gray area in the theory -- one might be led to think that this would affect a variable in the caller as well. Of course that's easy to explain, but it's clearer still if there's a general functional principle that references "upstream" are immutable -- they are simply a "view" of the calling process.
But what do I know?
- Dan
PS: And yes, there are various optimization aspects such as ways in which it might be more complicated to maintain two versions of the stack in a JIT implementation, etc, but this was not a driving force in the design.