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@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@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.
Hi.
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...
How many system classes refer to its variables by name? Why are there so many accessors missing? How much would the image grow just because of accessors? Would you like that in the small images? Why add so many methods when the design does not make them necessary? And then, would you use accessors even in Interval? I think that perhaps you think I'm proposing this for every object... but nope.
& blah. Andres.
Andres Valloud wrote:
How many system classes refer to its variables by name? Why are there so
Good point, shouldn't be that way, causes headaches all the time.
many accessors missing? How much would the image grow just because of accessors? Would you like that in the small images? Why add so many
These are all issues the "system/computer/<pick one>" should worry about. Optimization isn't anything we should worry about *at that level*.
methods when the design does not make them necessary? And then, would
Design should make it necessary ;-)
Michael
Hi.
How many system classes refer to its variables by name? Why are there so
Good point, shouldn't be that way, causes headaches all the time.
Let's add accessors to BitBlt! :)))... [KIDDING! KIDDING! AND JUST KIDDING!]
many accessors missing? How much would the image grow just because of accessors? Would you like that in the small images? Why add so many
These are all issues the "system/computer/<pick one>" should worry about. Optimization isn't anything we should worry about *at that level*.
I think it's a bit more than optimization... for instance, in the class Interval, it just has 3 instance variables...
methods when the design does not make them necessary? And then, would
Design should make it necessary ;-)
.... and right now I don't see any need for accessors in the Interval class. But that could be wrong in the near future...
Andres.
I agree Andreas -- but we could also point the finger at Smalltalk-80 and ask why doesn't it have a slot class that would allow us to change the meaning without having to worry about what the code looks like ...
Even Bob Barton's B5000 hardware in 1961 did the right thing here. What did it do? It looked in the slot in the Program Reference Table to see if there was a "descriptor" (a flagged word using a special extra bit). If there wasn't it did either the fetch of a literal value or a store of a literal value, as we would expect. But if there was a descriptor there, it looked to see if it was a procedure descriptor. If it was, then it called the procedure and set a bit that indicated whether a fetch or a store (a name call) was being attempted. The procedure was called normally and could test the bit and either return a value or (in the case of a store) another descriptor to be acted on by the store operator. This was almost perfect, except that store was an operator and thus would be waiting to act. This meant that it was not easy to make a sparse array (since the store operator would want to store a zero just like any other value in the array). It was pondering this in the sixties that got me thinking how nice it would be if store was only a token and not an operator at all, and that eventually led to the oop way of naming and acting. The problem in Smalltalk-80 is that the assignment to a variable is nonoop. Self did it better and tried to use the compiler to make up the speed difference. In the old legendary Smalltalk-72, you had to quote a variable ('foo <- 59 ) being assigned to (a la LISP), because in its oop scheme you were then talking to the symbol itself (foo) and it knew how to look itself up and rebind. An unquoted symbol as the receiver (foo <- 59) would dereference the variable to some object and the object would receive (<- 59) and could do whatever. I think that the Self way is pretty good and clean, since it extends referential transparency one more level. A little more of a metadescription would make things even nicer and more useful ...
Cheers,
Alan
-----
At 1:43 PM -0800 7/30/99, Raab, Andreas wrote:
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@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@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.
Alan Kay wrote:
I agree Andreas -- but we could also point the finger at Smalltalk-80 and ask why doesn't it have a slot class that would allow us to change the meaning without having to worry about what the code looks like ... [ ... ] I think that the Self way is pretty good and clean, since it extends referential transparency one more level. A little more of a metadescription would make things even nicer and more useful ...
Far be it for me to pick an argument with Alan, but I think that Smalltalk's accessing messages are just what he's looking for. If you only refer to an instance variable in the getter/setter accessing methods, you can change it freely, and the rest of your code never has to know. If you use any of the goodies for automatically generating accessing methods, then you never have to see any state except when you define a class.
Back when I taught Smalltalk regularly, we used the example of 2-D points, which have methods such as x, y, x:, y:, r, theta, r: and theta:. A client of this class has no idea or concern whether it actually stores its coordinates using Cartesian or polar coordinates. Only a benchmark test of the relative cost of translation and rotation operations will tell, and if you do one of these much more than the other, you're free to change the storage format of points with no other side-effects.
Stephen --
Yes, it works fine from the outside where one has to send messages, but it's the inside case of: foo <- 59 that Smalltalk-80 lets you do that I don't like. This absolutely means munge that variable and there is no override possible -- I like self's gentler and more general approach that handles this from the inside as well. In other words: of course I think we should use accessors (that was one of my earliest ahas!) -- As I said, what I don't like is that Smalltalk permits the above case (and so many people can't refrain from using it, only to get bitten by the early binding later on ....)
Cheers,
Alan
-----
At 2:30 PM -0800 7/30/99, Stephen Pope wrote:
Alan Kay wrote:
I agree Andreas -- but we could also point the finger at Smalltalk-80 and ask why doesn't it have a slot class that would allow us to change the meaning without having to worry about what the code looks like ... [ ... ] I think that the Self way is pretty good and clean, since it extends referential transparency one more level. A little more of a metadescription would make things even nicer and more useful ...
Far be it for me to pick an argument with Alan, but I think that Smalltalk's accessing messages are just what he's looking for. If you only refer to an instance variable in the getter/setter accessing methods, you can change it freely, and the rest of your code never has to know. If you use any of the goodies for automatically generating accessing methods, then you never have to see any state except when you define a class.
Back when I taught Smalltalk regularly, we used the example of 2-D points, which have methods such as x, y, x:, y:, r, theta, r: and theta:. A client of this class has no idea or concern whether it actually stores its coordinates using Cartesian or polar coordinates. Only a benchmark test of the relative cost of translation and rotation operations will tell, and if you do one of these much more than the other, you're free to change the storage format of points with no other side-effects.
--
Stephen Travis Pope -- http://www.create.ucsb.edu/~stp stp@create.ucsb.edu -- stp9@cornell.edu
On Fri, 30 Jul 1999, Alan Kay wrote:
I agree Andreas -- but we could also point the finger at Smalltalk-80 and ask why doesn't it have a slot class that would allow us to change the meaning without having to worry about what the code looks like ...
It sounds like the ideal situation would be to have a single standard way of accessing variables in source code, such that trivial accessor/mutator methods of the "^var" or "var := param" form would *never* need to be written. So, all you'd have to do is add a (non-trivial) accessor or mutator method, and then all variable accesses would be funneled through these, without having to change any source code.
I guess this must be how slots work in Self? (I wish I still had a Sun, so I could try out Self myself... :) )
(There would then still need to be an alternate way of accessing the variable directly in the cases where it was necessary to avoid an existing accessor/mutator method, but this use would be less common, and very private, and the source to do this should be more verbose than the standard access described above. I guess this is more or less what Andreas Raab just said in his last post.)
It would be fantastic if something like this eventually made it into Squeak... it would render this current argument obsolete. I don't know offhand what the best implementation would be, though. And it's obviously more of a blue-plane thing, and very non-ANSI compliant. :)
- Doug Way EAI/Transom Technologies, Ann Arbor, MI http://www.transom.com dway@eai.com, dway@mat.net
Alan Kay wrote:
I think that the Self way is pretty good and clean, since it extendsreferential transparency one more level. A little more of a metadescription would make things even nicer and more useful ...
The traditional implementation of Self has (among other things) a name, some flags and a value for each slot. The flags distinguish among the four kinds of slots like this:
switch ( slot.flags & TYPE_BITS ) { case CONSTANT : returnToCaller ( slot.value ); break; case DATA : returnToCaller ( receiver [ slot.value ] ); break; case ASSIGNMENT: receiver [ slot.value ] = getArgFromStack(); returnToCaller ( receiver ); break; case METHOD : callInSelf ( nativeCodeCacheFind(slot.value) ); break; }
While Self's system takes care of the 95% of the accessor methods that are trivial, non trivial ones require you to define and extra, "hidden" slot into which you store the actual value (for example, you have the non trivial #color and #color: slots that use the simple #rawColor and #rawColor slots). Thinking about this, I created a Self implementation which replaced the flags field with a pointer to native code, so the above fragment would now be:
callInSelf ( slot.nativeCode, slot.value );
For the CONSTANT, DATA and ASSIGNMENT slots, the nativeCode just does what the original fragment did with the value. For the METHOD slot, the nativeCode originally looks up value in the cache, but then it overwrites the nativeCode field with the result so this step is skipped the next time.
Now the whole idea was that the user would be free to create new types for slots (in Self and then compiled to native code) as a possible alternative to the #rawColor thing. I now feel that this was going to far.
-- Jecel
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andres Valloud -
Doug Way -
jecel＠lsi.usp.br -
Michael Rueger -
Raab, Andreas -
Stephen Pope