SystemNavigation and deprecated methods

Joshua 'Schwa' Gargus schwa at cc.gatech.edu
Fri Aug 15 14:54:10 UTC 2003


On Fri, Aug 15, 2003 at 09:48:50AM +0300, Daniel Vainsencher wrote:
> Roel, can you explain the stratification stuff in more detail?
> specifically, justify and qualify the statement "meta-level facilities
> must be separated from base-level functionality.".
> 
> Also, there is a package modeling mechanism that is currently being
> included in the official image, and whose information won't be lost even
> when it is superceded - PackageInfo. Is there any reason not to make at
> least the most useful of the messages discussed class extensions on
> Class? 

I am curious about this, too.

> (I don't know what you mean by "official, good, supported
> mechanism". If you want I can hold your hand as you reclassify the
> methods and then send you an outrageous bill ;-)
> 
> Joshua: I don't see why you differentiate between production code and
> the workspace. IMO, simplicity and conciseness are far more important in
> production than in workspace code - that's why we have a refactoring
> browser, not a refactoring workspace...

Agreed: it doesn't make as much sense to spend a lot of time massaging
workspace code, trying to make it read like elegant prose.

Where would you draw the distinction, then?  I offered a concrete example
where use of the global variable Navigator makes for simpler, more consise
code, but is undesirable for use in production code.  

Joshua

> 
> Daniel
> 
> Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> > 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