Squeak-dev August 1999

squeak-dev@lists.squeakfoundation.org

134 participants
348 discussions

RE: [BUG] ClassBuilder breaks class references
by Raab, Andreas 03 Aug '99

03 Aug '99

Bob, Thanks for the info - it will be fixed with update 1367 which will show up any time soon out there for the test pilots. Andreas -- +===== Andreas Raab ========= (andreasr(a)wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+ > ---------- > From: Bob Arning > Reply To: squeak(a)cs.uiuc.edu > Sent: Sunday, August 1, 1999 2:20 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient list not shown > Subject: [BUG] ClassBuilder breaks class references > > The introduction of ClassBuilder causes a problem in finding references to > a class. If there are references to a class and then the class is > recompiled, the cmd-shift-n no longer sees the references. This is due to > the fact that ClassBuilder creates a new association in Smalltalk while > methods referencing the class keep the old association (although with the > value updated). Since searches for references assume that the first > association remains valid (as in: > > Smalltalk browseAllCallsOn: (Smalltalk associationAt: cls theNonMetaClass > name) > > ), the search fails. I think I will leave it to someone who better > understands why the change was made to suggest a fix. > > Cheers, > Bob >

1 0

re: Re: Eliminating assignments and variable syntax (accessors)
by Alan Lovejoy 03 Aug '99

03 Aug '99

> ** Original Sender: Marcel Weiher <marcel(a)system.de> > > From: Stefan Matthias Aust <sma(a)netsurf.de> > > Resent-Sender: squeak-request(a)cs.uiuc.edu > > > > >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... > > Well, I guess that is the part that got sort of lost in the noise: > If there are no accessors, the compiler compiles 'accessor/mutator' > message sends to self as direct variable access. Therefore, the > object itself can access its own instance variables (and local > variables) even if the accessors are not defined, whereas in SELF > there is an automatic definition of accessors. > > Crucial difference. Yes, it is that. If one decides only at compile time whether "self foo" is a message send or a variable access, one must then recompile all methods that access the iVar foo as soon as an accessor is introduced. A worse problem is what to do when an accessor is introduced **in a subclass**. Should that change the meaning of code in a superclass, or not? Worse, suppose the accessor does lazy initialization, but there are references to the iVar where lazy initialization would be either incorrect or at least undesirable? --Alan

1 0

RE: [Interval Problem] 2 cents
by Raab, Andreas 03 Aug '99

03 Aug '99

And get from late binding (which is the entire point of Smalltalk) to early binding (which is the entire point of C) since you can't override any immediate inst var accesses. Argh! How I hate this... Sorry, couldn't resist. Andreas -- +===== Andreas Raab ========= (andreasr(a)wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+ > ---------- > From: Andres Valloud > Reply To: squeak(a)cs.uiuc.edu > Sent: Friday, July 30, 1999 2:47 PM > To: Squeak > Cc: recipient list not shown > Subject: [Interval Problem] 2 cents > > Hi. > > I think it would be a good idea to remove the self sends from any fix, > and replace > > self someInstanceVariablePlainAccessorMethodNamedTheSame > > with > > theInstanceVariableItself. > > Because then you start adding message sends and that is time expensive. > > Andres. > >

7 8

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

03 Aug '99

> From: Alan Lovejoy <sourcery(a)pacbell.net> > > ** Original Sender: Marcel Weiher <marcel(a)system.de> > > Well, I guess that is the part that got sort of lost in the noise: > > If there are no accessors, the compiler compiles 'accessor/mutator' > > message sends to self as direct variable access. Therefore, the > > object itself can access its own instance variables (and local > > variables) even if the accessors are not defined, whereas in SELF > > there is an automatic definition of accessors. > > > > Crucial difference. > > Yes, it is that. > > If one decides only at compile time whether "self foo" is a message > send or a variable access, one must then recompile all methods that access > the iVar foo as soon as an accessor is introduced. Exactly! The difference to now is that right now I'd have to manually modify the source code of all the methods doing access, whereas with the change the system can do the recompilation automagically. I never suggested this was a panacea, just that it is a *little* better than what we have now. > A worse problem > is what to do when an accessor is introduced **in a subclass**. > Should that change the meaning of code in a superclass, or not? Again, ask yourself what happens now. There, you've got the initial answer. > Worse, suppose the accessor does lazy initialization, but there are > references to the iVar where lazy initialization would be either > incorrect or at least undesirable? Then you shouldn't use the basic-accessor to do the lazy initialization. Marcel

1 0

re: [Interval Problem] 2 cents
by Alan Lovejoy 03 Aug '99

03 Aug '99

> ** Original Sender: "Jarvis, Robert P." <Jarvisb(a)timken.com> > > Well, <grumble-snarl>, I was *about* to make the point that it's easier to > search for method references than for variable references, except that I > just figured out how to do the latter easily (there's an instructive lesson > here about how one (well, *this* one, anyways :-) gets into certain patterns > of though and action, and other thoughts and actions become unthinkable and > undoable, but I digress...) and so it looks like that portion of my argument > just came off the track. Interesting that you mention "Smalltalk Best > Practice Patterns". I seem to recall that Kent actually switch-hit on this > issue, coming out both in favor of and against accessors/direct access. I > think his final call on it was "horses for courses", and I forget what the > guidelines were (book's at home, I'm not). But the whole point of my position is precisely that the "always use accessors" rule is too simplistic, not that it's never a good idea. It often is a very good idea, which is why Kent "switch hits" on the issue. > As far as "maintainability" goes, say that you have to modify your actions > upon "setting" a value to include a whole bunch of extraneous crud. For > example, let's say you've got a simple accessor that sets the desired > shipping date for an order. Later the users come along and say, "Oh by the > way, if you're setting the shipping date and the customer's desired receipt > dates haven't been set, go ahead and set those to some default values, > there's a good lad, off you go...". If you've directly accessed the > "shipping date" variable directly you'll now have to go back and either A) > change the code (in potentially many places) so it sets the other variables > as well, depending on some conditional logic, or B) write and retrofit an > accessor that'll do this for you. I'll grant you that you can always do > (B), but if you've written and used the accessor from the beginning IMHO > you're much better off. Ah, but you appear to be referring to mutators, n'est-ce pas? If so, I have already said I feel that the case for using mutators is much stronger. (To me, "accessors" refers to methods that are used to read variable values, and specifically not to methods that are used to assign values to variables). --Alan

1 0

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

03 Aug '99

> From: Stefan Matthias Aust <sma(a)netsurf.de> > Resent-Sender: squeak-request(a)cs.uiuc.edu > 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. Funny, that was *exactly* the idea of my proposal. You *always* use "message" syntax to access slots, though that message syntax is modified slightly in order to have less typing and integrate local-vars. You could just as well use full message-send syntax for this, though I would find that a little verbose. > 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. Because I don't want to go the SELF way, but rather make an absolutely minimal change. > >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... Well, I guess that is the part that got sort of lost in the noise: If there are no accessors, the compiler compiles 'accessor/mutator' message sends to self as direct variable access. Therefore, the object itself can access its own instance variables (and local variables) even if the accessors are not defined, whereas in SELF there is an automatic definition of accessors. Crucial difference. Marcel

1 0

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

02 Aug '99

> From: Travis Griggs <tgriggs(a)keyww.com> > There is always a reciever followed by a message send. I'm always > amused when I read code from Java or C++ where most of the message sends are of > the implicit style (ala good ol' functions) and authors obvious understanding > of > the object/messaging pardigm is abviously nil. I'm not averted to getting rid > of/or changing assignment syntax, but please don't do the implicit (or hidden) > message sending thing. I think there is some misunderstanding here. The visible change for (reading) accessors/var-access would be exactly nil, nada, zip, zilch, nothing. To illustrate, before: myInstanceVar doSomething. after: myInstanceVar doSomething. The difference is that right now, this expression is always treated as directly accessing the variable, while with the proposal, it would be treated as calling the accessor (which is optimized away again if, for example, there is no accessor). So the *visible* change is really very, very minimal. The only visible change is variable writing / mutators, which change from: myInstanceVar := newValue to myInstanceVar: newValue. That really doesn't seem like such a big deal to me. ( if you missed it, the '=' disappeard). Again, the importan point is that the semantics have changed. Marcel

2 1

[SqT][BUG?] Can't debug after updating to 2.5test
by Marcel Weiher 02 Aug '99

02 Aug '99

After fetching the test pilot updates, trying to debug gets me the error Message not understood "classOf:" The culprit is Inspector>>objectClass ^ObjectInspector classOf:object. In my system, ObjectInspector is not defined and there isn't a single implementation of #classOf: either. Marcel

1 0

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

02 Aug '99

In my opinion this is an example of premature optimization, and flies directly in the face of well-documented Smalltalk best practices. Use of accessor methods simplifies maintenance, increases browsability, and in my opinion is a whole lot easier to work with. When you have a known performance problem you're trying to solve you can then potentially drop internal accessor sends if you think that's going to make a difference. (Personally I doubt very much that the elimination of some simple accessor sends is going to affect much of anything. Poor algorithm choices are far more likely to be the culprit in any performance problem than accessor sends). If you want to drop the use of accessors in your own code then you should do so. I'll continue to use accessors. Bob Jarvis The Timken Company > -----Original Message----- > From: Andres Valloud [SMTP:sqrmax@cvtci.com.ar] > Sent: Friday, July 30, 1999 5:48 PM > To: Squeak > Subject: [Interval Problem] 2 cents > > Hi. > > I think it would be a good idea to remove the self sends from any fix, > and replace > > self someInstanceVariablePlainAccessorMethodNamedTheSame > > with > > theInstanceVariableItself. > > Because then you start adding message sends and that is time expensive. > > Andres. >

2 1

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

02 Aug '99

>So, each and every time the code generated for > > myInstanceVar:newValue > >is encountered at run-time, wouldn't a search of one or more method >dictionaries be needed to see if there is a method available and only >fall back to direct access if none were found? In theory, yes. But assuming that there's a clean interface to adding new methods to the system, this interface method can perform the needed test and then recompile all affected methods accordingly. >And this is an objection to the "always use accessors" argument that may >not have been stated clearly enough: While understanding the current >effects of "self x: 1" is a little more difficult that understanding >"x _ 1", understanding what effect "self x: 1" might have in the future >is impossible. Good point! bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

1 0

Jump to page: