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
|