just to share that with you Begin forwarded message:
> From: Daniel Ingalls <[email protected]> > Date: December 24, 2008 8:48:09 PM CEST > To: Stéphane Ducasse <[email protected]> > 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. > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
