Stef, It was not until I re-read this that I took note of just who had all this great insight into computing. I fully agree about the debugging benefits of immutable arguments. The same argument leads me to want to avoid name collisions between temporary and instance variables.
Please tell Dan that from where I sit, he knows a LOT :) Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bsch...@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.duca...@inria.fr 12/24/08 2:56 PM >>> just to share that with you Begin forwarded message: > From: Daniel Ingalls <dan.inga...@sun.com> > Date: December 24, 2008 8:48:09 PM CEST > To: Stéphane Ducasse <stephane.duca...@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. > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
