SystemNavigation and deprecated methods

Daniel Vainsencher danielv at netvision.net.il
Fri Aug 15 06:48:50 UTC 2003


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 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...

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