Squeak-dev August 1999

squeak-dev@lists.squeakfoundation.org

134 participants
348 discussions

RE: RE: Eliminating assignments and variable syntax (accessors)
by agree＠carltonfields.com 02 Aug '99

02 Aug '99

Perhaps I'm stating the obvious, but isn't there a potential problem here? In particular, let us consider: instvar := <expression> Presently, this unambiguously means munge instvar and replace it with the answer to the expression. That's fine so far as it goes, and we've discussed at length the upside/downside of using it in raw form. But sometimes we MUST be able to articulate precisely this function. For example, in the accessor: instvar ^instvar and the setter: instvar: anExpression ^instvar := anExpression Clearly, if every reference to instvar is treated as a call to method instvar, and every "assignment" to instvar is treated as a recusive call to method instvar:, neither of the definitions above will serve, resulting in infinite recursive regress. (Now that's inefficient!) Of course, we could simply check before doing the substitution that has been proposed here, and use the ordinary Smalltalk semantics for "instvar" when referenced within a message of the form "instvar" or "instvar:" This seems to me cumbersome and ugly, because it means that the expression x := y depends entirely on its context. Further, should you adopt this solution, you no longer have a way to make a recursive call within a setter or getter without the ugly expedient of a call to a second service method to do the recursion (though I can't at all imagine an exemple where I would want to do so). Am I missing the point, or is this "solution" harder than it seems at first blush?

2 1

RE: RE: Eliminating assignments and variable syntax (accessors)
by Jarvis, Robert P. 02 Aug '99

02 Aug '99

Thanks for the explanations. What troubles me is that the grammar of the language now becomes more complex, in my opinion, rather than simpler. With this proposal Smalltalk would now have "normal" message sends, of the form "<object> <message> {<optional arguments and keywords>}" and "implicit" message sends, of the form "<message> {<optional arguments and keywords>}". Maybe I'm just in reactionary mode today (I'll be one of the first against the wall when the revolution comes, no doubt :-) but it just doesn't seem to "flow" as nicely to me. Maybe we should go a step further and consider how to eliminate variables. Without variables and their required assignment syntax this issue becomes moot. Functional Smalltalk, anyone? (Before anyone gets too wound up about this, let me hastily add that the functional languages I've seen are not my cup of tea, heavy on the static strong typing and light on the practically useful. I do think that some of the ideas of functional programming, such as the elimination of state and delayed expression evaluation, could be potentially useful, but I haven't a clue how to go about this). Bob Jarvis The Timken Company > -----Original Message----- > From: Marcel Weiher [SMTP:marcel@system.de] > Sent: Monday, August 02, 1999 3:16 PM > To: squeak(a)cs.uiuc.edu > Subject: Re: RE: Eliminating assignments and variable syntax > (accessors) > > Thanks for taking the time in looking over my (admittedly pretty > rough) idea. > > > From: "Jarvis, Robert P." <Jarvisb(a)timken.com> > > > > I don't like the idea of implicit targets. One of the great > beauties of > > Smalltalk is its simple and very regular grammar. In my opinion adding > > implicit targets would make the grammar more complex and less regular > > without a corresponding gain in clarity or expressiveness. > > Yes, I also don't want to mess the syntax up. However, for > 'reading' accesses, there is no (visible) change in syntax, it's just > that what used to be variable references are now interpreted as > message sends. That seems like a simplification to me. > > The only 'addition' is that for assigning values, instead of writing: > > a := b. > > you would write > > a: b. > > Considering that the colon syntax is also already in use, and that > := gets removed, that also seems to be a simplification of the > visible syntax, overall (a slight complication and a medium > simplification). As a matter of fact, the compiler could treat a:= > as equivalent to a: I have to admit that I haven't considered what > this will do to the compiler, though. > > > I just don't see > > a great advantage here. It seems more like a hint to the compiler > than an > > aid to the human. > > Well, the aid is that there is now only message sends, assignments > have been eliminated from the language or at least hidden from view. > The practical benefit I have in mind is that the decision wether > access to an instance variables is direct or via accessors is made in > one place instead of everywhere the variable is accessed. > Currently, if I have direct instance variable access, I write. > > myInstanceVar doSomething. > > If I have accessors, I write > > self myInstanceVar doSomething. > > *everywhere* I use myInstanceVar. The same goes for write-access: > > myInstanceVar := newValue > > versus > > self myInstanceVar:newValue. > > The problem is that changes to the access policy are very expensive > because every method *accessing* the instance-var/accessor has to be > changed. Therefore, your (absolutely correct, IMHO) proposition that > all instance var access be done with accessors first and directly > only when absolutely necessary means that a lot of code has to > potentially be modified in the latter case. With lots of coders > being prone to premature optimiziation, they will opt for direct > access instead, especially since it is also less typing. > > With my proposal, code can always be written as if it is using > accessors, making it non-brittle, but at the same time it enjoys all > the benefits cited for direct variable access (privacy, speed, less > typing, etc.) So, I just write > > myInstanceVar doSomething. > and > myInstanceVar:newValue. > > and this very same code will use accessors if available or direct > access if not. > > > Also, if := is eliminated how is a reference assigned to > > a temporary variable? > > Trickery. Just like with instance variables, the compiler detects > that there is a local variable of that name and emits the direct > access code instead. I know this sounds a little insane (turn the > access into a message send and then auto-reduce it back to an > access), but there is some method to the madness :-) > > Regards, > > Marcel

3 2

Re: Eliminating assignments and variable syntax (accessors)
by Stefan Matthias Aust 02 Aug '99

02 Aug '99

>I've been following the accessors thread with great interest and >have a rough sketch for eliminating direct variable access from >Squeak. [...and replace it with the way SELF accesses slots] While I'm a big fan of SELF's idea to omit classes and use only objects which play different roles I don't like the way SELF tried to minimalize the syntax. They simulated local and object-level variables using slot accessors (which isn't bad in itself) and represented this in the syntax (which makes the code unusual and alien-looking IMHO). It was Guy Steele's speach at OOPSLA 98 which convinced me that too less syntax is even more harmful to a language than too much. IMHO, variable access should also look like variable access. (I'd even go so far and use "a[1] := 4" instead of at:put: for array access but that's another story) I don't care whether the compiler uses direct slot access or accessor methods to set and get values but I don't want to see that implementation detail on the language level. Actually I like the way Python deal with this. Python has a number of low level methods you can overwrite to change the behavior of default operations like + or - but also for things like assignments, slot access or indexed access. I think this is only reason why Python is generally considered as very easy to learn. As a beginner you don't have to deal with these implementation issues but as an expert, you can access the meta level. >Prepending 'thisContext' to the lookup chain for implied messages >brings arguments and local variables into the game, at least >conceptually (though of course a normal context won't respond to >these messages). Why not? This is how SELF works. >Variables can be kept somewhat >private by not creating accessors for them. Decisions to use direct >variable access are localized, not spread over all the code that >makes use of the variable. I don't understand the last point? How can you restrict the access by not providing accessor methods if this would also mean that nobody can access them. As I understood, you wanted to get rid of ":=" and direct variable access altogether. Without (public-accessable) methods you cannot use these variables... bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

1 0

RE: Eliminating assignments and variable syntax (accessors)
by Jarvis, Robert P. 02 Aug '99

02 Aug '99

I don't like the idea of implicit targets. One of the great beauties of Smalltalk is its simple and very regular grammar. In my opinion adding implicit targets would make the grammar more complex and less regular without a corresponding gain in clarity or expressiveness. I just don't see a great advantage here. It seems more like a hint to the compiler than an aid to the human. Also, if := is eliminated how is a reference assigned to a temporary variable? I suspect there's much here I'm not seeing... Bob Jarvis The Timken Company > -----Original Message----- > From: Marcel Weiher [SMTP:marcel@system.de] > Sent: Monday, August 02, 1999 12:13 PM > To: squeak(a)cs.uiuc.edu > Subject: Eliminating assignments and variable syntax (accessors) > > > I've been following the accessors thread with great interest and > have a rough sketch for eliminating direct variable access from > Squeak. > > The basic idea is to replace the binding of names to variables with > messaging. > > In order to accomplish this, the notion of messaging with implicit > targets and a lookup chain is introduced. For example, messages to > self do not need to be prefixed with 'self'. > > self hi. -> hi. > self hi:newHi. -> hi:newHi. > > Prepending 'thisContext' to the lookup chain for implied messages > brings arguments and local variables into the game, at least > conceptually (though of course a normal context won't respond to > these messages). Appending an environment pointer might be used to > add namespaces and broadcasts. > > Thus the syntactic overhead of accessors compared to direct access > would be eliminated by an implicit target for message sends. > > The compiler can compile implicit message sends either as real > message sends or as direct variable access, depending on various > factors. (This is deliberately vague). > > I think this sketch addresses most of the issues raised on both > sides of the debate (and sounds suspiciously like SELF). The syntax > is simplified and := can be removed. Variables can be kept somewhat > private by not creating accessors for them. Decisions to use direct > variable access are localized, not spread over all the code that > makes use of the variable. > > Marcel

2 1

Re: RE: Eliminating assignments and variable syntax (accessors)
by Marcel Weiher 02 Aug '99

02 Aug '99

> From: "Ivan Tomek" <ivan.tomek(a)acadiau.ca> > > I would like to join those who oppose this valiant proposal. The main > problem for me is that it complicates the beautifully simple and uniform > syntax of Smalltalk: As an example, a: b does not have a receiver. I > consider the simple syntax one of the great things about Smalltalk > both for learning and for code readability. Well, as I explained to Jarvis, my proposal actually simplifies the syntax by removing the "receiver" entirely and uniformly because all message sends have to start with the implicit receiver. I hadn't thought about this before, but the fact that you have to *name* a direct receiver for message sends was one of the things that was complicating a couple of other ideas. Hmmm... It does look a little strange, though. :-) Marcel

1 0

Re: Eliminating assignments and variable syntax (accessors)
by Marcel Weiher 02 Aug '99

02 Aug '99

Yes, this is definitely one of the issues I alluded to in >The compiler can compile implicit message sends either as real >message sends or as direct variable access, depending on various >factors. (This is deliberately vague). and one of the reasons I presented it as a *rough sketch* and not "the solution". > From: agree(a)carltonfields.com > > Perhaps I'm stating the obvious, but isn't there a potential problem here? > In particular, let us consider: > > instvar := <expression> > > Presently, this unambiguously means munge instvar and replace it with the > answer to the expression. That's fine so far as it goes, and we've discussed > at length the upside/downside of using it in raw form. > > But sometimes we MUST be able to articulate precisely this function. For > example, in the accessor: > > instvar > > ^instvar > > and the setter: > > instvar: anExpression > > ^instvar := anExpression > > Clearly, if every reference to instvar is treated as a call to method > instvar, Well, one could argue that plain accessors are special enough that they could be treated specially by the compiler, but it turns out that this isn't necessary. What I described actually turns such calls into direct access unless there is an accessor... > and every "assignment" to instvar is treated as a recusive call to > method instvar:, neither of the definitions above will serve, resulting in > infinite recursive regress. (Now that's inefficient!) ....and you could definitely argue that inside the definition of the accessor, the accessor does not yet exist, so instvar:newValue newValue isOk ifTrue: [instvar:newValue]. would actually work and not cause in infinite regress, although it certainly would look a little peculiar. Maybe the way to look at it would be to write this as instvar:newValue newValue isOk ifTrue: [super instvar:newValue]. although that raises another couple of problems... Marcel

1 0

RE: metaclasses
by Jarvis, Robert P. 02 Aug '99

02 Aug '99

Try "The Art of the Metaobject Protocol", by Kiczales, Des Rivieres, and Bobrow (ISBN 0262610744). This book is about Lisp, but is pretty much applicable to Smalltalk as well. Bob Jarvis The Timken Company > -----Original Message----- > From: Jason Karney [SMTP:jason@NetGenics.com] > Sent: Monday, August 02, 1999 1:31 PM > To: squeak(a)cs.uiuc.edu > Subject: metaclasses > > Hi, > > I am interested in learning more about meta-classes and how do > Object/Behavior/etc. really work. Besides browsing them, can anybody > recommend a > good roadmap? Thanks. > > Jason

1 0

RE: [Interval Problem] 2 cents
by Jarvis, Robert P. 02 Aug '99

02 Aug '99

Perhaps there should be an IntervalIterator class which holds the progress of an iteration across an Interval. This would help to separate the concept of Interval (which would then specify only the start, end, and step values for the Interval) from the concept of iteration, which produces the intermediate values. AND you could conceivably have mutiple iterations going on simultaneously on the same Interval. And if you extend this idea to some of the other collections it might prove useful. Maybe. I think... All that being said, Michael, I really like your rewrite of Interval>>do:. :-) Bob Jarvis The Timken Company > -----Original Message----- > From: Michael Rueger [SMTP:Michael.Rueger.-ND@disney.com] > Sent: Friday, July 30, 1999 6:37 PM > To: squeak(a)cs.uiuc.edu > Subject: Re: [Interval Problem] 2 cents > > Andres Valloud wrote: > > > do: aBlock > > > > | aValue | > > aValue _ start. > > step < 0 > > ifTrue: [[stop <= aValue] > > whileTrue: > > [aBlock value: aValue. > > aValue _ aValue + step]] > > ifFalse: [[stop >= aValue] > > whileTrue: > > [aBlock value: aValue. > > aValue _ aValue + step]] > > > > I do not see any accessor there. > But you should ;-) > > A really objectified version would go even further like > > do: aBlock > [self atEnd] whileFalse: [ > aBlock value: self currentValue. > self step] > > This would even increase performance because you could optimize > different atEnd and step methods for e.g. ints and floats or points etc. > And currentValue could like > > currentValue > currentValue ifNil: [currentValue := self start]. > ^currentValue > > Q.E.D. > ;-) > > > Michael > > > -- > > "To improve is to change, to be perfect is to change often." > Winston Churchill > +------------------------------------------------------------+ > | Michael Rueger | > | Phone: ++1 (818) 623 3283 Fax: ++1 (818) 623 3559 | > +--------Michael.Rueger.-ND(a)online.disney.com----------------+

1 0

re: re: Please use accessors!
by Alan Lovejoy 02 Aug '99

02 Aug '99

Note: this reply is just to you, not also to the Squeak list: > ** Original Sender: "Carl Gundel" <morphic(a)hotmail.com> > >Poorly designed code will be brittle. But I am convinced that blaming > >direct iVar access as the culprit is an oversimplification. > > Okay, but I didn't say that direct ivar access was the sole culprit of > brittle code. Writing code for myself, I sometimes don't use accessors, but > when working on a team I usually automatically generate them. > > It isn't possible to pin down any "always right" programming practices. In > my own experience, next year I won't completely agree with everything I > might say today. ;-) > > -Carl Yup. I disagree with my previous self all the time. Since I see the same characteristic in just about everybody, I can only conclude that we all would benefit from toning down the vociferousness with which we propound our dogma. As my father was fond of saying: "The best way to handle a vicious dogma is with a big stigma." :-). My friend Ken Auer has always been suspicious of The Methodologists. I've heard him accuse them more than once of having nice theories that obviously were never tested against real life, practical problems. Anyway, I hope to see you again at the Squeak BOF in Denver (OOPSLA '99). We can discuss this at length over a cup of coffee... --Alan

1 0

re: Please use accessors!
by Carl Gundel 02 Aug '99

02 Aug '99

>From: Alan Lovejoy <sourcery(a)pacbell.net> >Reply-To: squeak(a)cs.uiuc.edu >Subject: re: Please use accessors! > > ** Original Sender: "Carl Gundel" <morphic(a)hotmail.com> > > >From: Alan Lovejoy <sourcery(a)pacbell.net> > > >Reply-To: squeak(a)cs.uiuc.edu > > <big snip> > > >8. Given the above, I would avoid being dogmatic on this > > >issue. I think the fact that so many good Smalltalk programmers > > >still access instance variables directly, and that code that commits > > >this "sin" has lasted unchanged for so long, should cause one to > > >at least question whether or not it's all that sinful. > > <snip> > > > > Thanks for the brain dump Alan! :-) > > > > I understand the pragmatics of this issue well, but I feel compelled to >make > > a counterpoint about the above. Code that accesses ivars directly can >be > > brittle. In particular, code which uses both direct access and accessor > > methods on the same ivars can behave in unpredictable ways. Sometimes >such > > code survives for a very long time because it is brittle and hard to > > understand, and no one wants to touch it for fear of breaking it. > > > > I tend to defer writing code which accesses ivars directly until >performance > > tuning time. I wish I never had to write such code because it hurt the > > maintainability and extensibility of my design, but I live in the real >world > > (oh Bah!). > > > > Thanks again! > > > > -Carl > >Poorly designed code will be brittle. But I am convinced that blaming >direct iVar access as the culprit is an oversimplification. Okay, but I didn't say that direct ivar access was the sole culprit of brittle code. Writing code for myself, I sometimes don't use accessors, but when working on a team I usually automatically generate them. It isn't possible to pin down any "always right" programming practices. In my own experience, next year I won't completely agree with everything I might say today. ;-) -Carl _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

Jump to page: