SystemNavigation and deprecated methods

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Fri Aug 15 03:29:08 UTC 2003


This is mostly a me too.  As long as we are careful to separate the
"convenience" methods/globals from the "production" methods, there's
no harm in the convenience methods existing.  If you insist on leaving
out the convenience methods, then you have just made the system more
inconvenient to interact with.  In production code, you can write

'SystemNavigation default allCallsOn: aSelector from: aClass'

but if I'm typing in a workspace, why shouldn't I be able to type:

'Navigation allCallsOn: aSelector from: aClass' or even
'aClass allCallsOn: aSelector'

Disallowing these discourages exploratory workspace programming, and
moves Squeak towards being Java (VisualAge Java has a Workspace, but
it is hell to use because you have to type way too much).  There are
definitely reasons to use the long expression in production code,
since it provides a flexible layer of indirection that's very helpful
for all the nifty stuff going on in Berne.  But like Andreas said,
having the convenience methods there can't kill you if they're not
called.

Granted, it takes discipline to make sure that calls to the convenient
methods don't creep in to the image.  Perhaps it was in this sense that
you meant that the convenience methods "will kill you".  However, we have
a much better code review process in place now, so I don't think that 
this would turn out to be a serious issue.

If it turns out to be a bigger problem than I think, then we've just
found a Research Opportunity.  Perhaps some sort of composition model
could be used so that the convenience methods could be used in DoIts
and quick Morphic hacks, but would not be visible when writing
production code.  I don't know exactly how this would work, but hey,
you're the SCG and I'm working on graphics; you figure it out ;-)

Joshua



On Fri, Aug 15, 2003 at 02:34:09AM +0200, Andreas Raab wrote:
> Hi Roel,
> 
> > It is not as simple just saying that The Right Thing is this or
> > that, since it heavily depends on what you want to do. What 
> > responsibilities you give to an object is what makes OOP hard
> > (not especially the programming). And these responsibilities
> > change over time as the system evolves. Squeak is evolving
> > right now, so what once was a clear and good decision to
> > let Classes know about the structure of their instances,
> > about how to create instances and about all the
> > meta-programming structure does not necessarily hold anymore.
> 
> I certainly agree, but so far no convincing argument to the contrary has
> been made, except from either stating that it is "bad" (with five or more
> exclamation marks attached ;-) or that it is Not The Right Thing To Do.
> 
> > For example, if you want to build a browser that works on code not
> > inside your image, then having these 'right' methods there will kill
> > you.
> 
> 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?
> 
> 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? ;-)))
> 
> 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.
> 
> > 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.
> 
> > 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) 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.
> 
> Cheers,
>   - Andreas
> 



More information about the Squeak-dev mailing list