SystemNavigation and deprecated methods

Roel Wuyts wuyts at iam.unibe.ch
Fri Aug 15 12:50:55 UTC 2003


Hi,

> And why would that be? Perhaps you haven't read my message carefully 
> but I
> have very clearly stated that for something like a browser it seems 
> quite
> appropriate to have a navigator at hand. But given that I know I am 
> talking
> to classes in my image if I want to inquire one of the classes about 
> certain
> properties, why would it kill me if these methods were there?

Because you then have base-level code that directly accesses meta-level 
methods. If ever you want to remove reflection from your image you risk 
running into big problems, because it is very hard to determine all the 
places in the code where the reflection is actually used. This is an 
issue for deployment and fir using Squeak on small devices where it 
would be great to remove it if your 40k application does not do any 
perform: etc. To make it clear: this does not mean that I want 
reflection to go (I love reflection; I write papers about reflection 
:-) ). But I want to see where it is used, for analysis, for 
optimization, for new kinds of tools, etc.

> In addition, in order to be even able to talk to some code that is not
> inside your image you still need to have a "handle" to refer to. If 
> you call
> that handle an "object" then this object may implement the appropriate
> queries. And, lo and behold! The mere existence of the methods will 
> not kill
> you. Isn't it amazing what you can do if you think object-oriented? 
> ;-)))

Sure. Every problem in computer science can be solved by introducing an 
extra level of indirection :-)
No, serious, you run into problems because if you introduce a simple 
proxy (let's call it 'aProxy', instance of class MyProxy) for an object 
a (instance of A), then what happens if you evaluate 'aProxy class 
selectors'? That is the point I wanted to make. No object-orientedness 
will save you there, I'm afraid :-(

> I think that the major trouble we're having in this discussion is 
> caused by
> an assumption that every last place in the system absolutely has to 
> use the
> most general mechanism available. That is wrong as in 99% of all of the
> common cases a simple solution is just what you need. If you can 
> provide for
> generalizations by, for example, providing a navigator in the browser 
> and
> encourage people to use that navigator when they hack their own 
> browsers
> that's fine. But don't forget about the many situations in which we 
> just
> want a quick answer to some question! You're making it incredibly hard 
> to
> use the system in the most convenient way, which, by the end of the 
> day,
> means we're loosing a significant amount of productivity.

Yes, that's why I like to have responses like yours; no question about 
it. Note that we are having two discussions at the same time in this 
thread, I think. One is the general overall discussion (all the stuff 
above and the stratification below, etc.). The other one is the 
concrete problems that started the whole thread in the first place. For 
the latter, I thought that you only objected to some of the methods 
being gone from class. Is that right? If so, could you give a concrete 
list?

>
>> On to the pink plane! Let's make Squeak a better system.
>
> Better for whom? For researchers to study, for newbies to learn, for
> programmers to use? For two out of the three I would claim that the 
> "better"
> system is the one where these things can be gotten to easily and
> conveniently.

Hah, ouch. Touché :-) Our goal is to have it for all three, actually. 
Some solutions have been proposed in some other mails in the thread, so 
Stef will take one of those (like he explained) when he has some more 
time. Again, I want both :-) So just bring us back to earth when you 
think we are starting to float too high in our research balloon :-)

>
>> PS: The reason is the 'stratification' I talked about in the other
>> mail: you are assigning responsibilities to Class which are not
>> necessarily the right thing. A detailed example is in an upcoming
>> Bracha&Ungar paper that talks about techniques to have a clean MOP in
>> OO languages (so basically about Mirrors and its different
>> incarnations in Self, Strongtalk and the Java Debugging Interface).
>> The distributed browser example is what they use to illustrate
>> 'stratification', one of the concepts they introduce.
>
> Please send me a copy of this paper as soon as it is available.
> 'Stratification' (for which the definition is rather unclear to me; it 
> would
> be helpful if you could give us an understanding of what is actually 
> meant
> by the term)

The clear division between base level code and meta level code, as I 
tried to made clear in the paragraphs at the beginning of this mail. By 
itself stratification is not that new; for example, I need it in Soul, 
since I have to marry two different languages. You clearly see the 
difference between the logic (meta) code and the Smalltalk (base) code. 
So there you have to make a clear separation or suffer the 
consequences. When the meta language and the base language are the 
same, and the representation of the language are objects just as base 
level objects (the Array object, for example), it is very easy to write 
statements that jump between base and meta level code all the time 
('myObject class selectors', for example). By itself this is not a 
problem, until you suddenly need to change some part of the 
representation (because your things do not live in your image anymore). 
Then all thse seemingly ok and very clear statements become quite 
difficult. Again, this is not to say that I want such a complete system 
in Squeak: that would be a research goal (and you'll end up with 
Strongtalk or something very similar). But that is part of the 
motivation why we make the separation, implementing it on a separate 
class. Then we can still add class extensions to point to these things, 
or make a global variable to hold the instance, etc.

> may be a useful thing for system structuring but by the end of
> the day it's efficiency and intuition that counts. And as much as I 
> like
> well-factored systems, if they are divided in ways which only make it 
> hard
> for users to actually get the results they want, then that factoring is
> simply useless. Mind you, we are not talking about a pure research 
> prototype
> here - some people actually want to use that system.

That is my goal. You'll see what we can come up with in a research 
context :-) I am aware that the KCP is not a research thing.

>
> Cheers,
>   - Andreas
>
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org



More information about the Squeak-dev mailing list