>From the keynote:

> Again we really blew it we didn't do a damm thing beyond
> adding more methods to the image than people could possibly
> understand. A race to add the most features to the image. Maybe we
> need a pico-Smalltalk.

This is one thing I constantly struggle with in Squeak.  It's hard to tell
what the Really Important objects and methods/protocols are.  The obvious
whipping boys are classes like Object and String and Morph where everybody
expects a dumping ground of backstop methods.  All of my
strong-typing-weenie instincts tell me that Morph has no business knowing
about piano rolls, but hey, I'm new here, and I can see sense in it when I
squint just right.

But there's stuff like SystemWindow where there appear to be n different
ways to do things like add panes, with some of the methods partially
overlapping others.  So I go read a bunch of examples, and hopefully I
figure out what's the important core of the object and what methods just
there as conveniences.  Sometimes I don't, and I end up with all my
SystemWindows wanting to be black (because I'm not doing the right thing
with models?) or I misuse PositionableStreams or whatever.

Method categories do help some in hiding details.

It would be nice if there was some way of explicitly viewing these Really
Important methods.  What do I need to understand about an object---which, if
I don't know about these methods, I won't Get It?

There are two obvious mechanisms floating around to help supply this
information.  The first is the reification of protocols, as a
documentation/browsing tool.  The second is modularization.  (The piano roll
methods on Morph would be easily traceable to the PianoRollMorphs module;
addMorph: would be traceable to MorphicCore.)

I was also thinking about a collaborative filtering tool.  Right click on a
method name in a browser and in the popup menu are "this method is IMPORTANT
to understand" "this method is not important".  Methods people had scored
high would get some kind of visual cue (darker? bolder?).  Yeah, there's the
small problem of collective agreement on criteria, but....

Using modularization in this way requires explicit statement of programmer
intent.  ("These piano roll methods belong to the Piano Roll module, so I'm
not going to just dump them out with MorphicCore.")  Reified protocols
certainly can benefit from explicit statement, but there's this tantalizing
possibility we may be able to extract intent from what's already there.

Any progress in this direction looks expensive.  Is it cheaper than a giant
project for class documentation in prose? Maybe.

> Perhaps we need an owner slot to identify who created me.
> This would solve lots of security sandbox issues.

That sounds familiar.  I spend/spent a lot of time working on MOO.  MOO is a
persistent, object-oriented, prototype-based, multiuser, multiprogrammer
network app development environment, most often used for building
"text-based virtual realities"---muds, adventure games, whatever you wanna
call 'em.  VM download at http://sourceforge.net/projects/lambdamoo , and
uh, google for more documentation.

MOO is in a very small set of dynamic language systems with full persistence
that explicitly support multiple programmers with varying levels of trust
between them.  For instance, the LambdaMOO (
telnet://lambda.moo.mud.org:8888/ ) image has been running for ten years
now, with hundreds if not thousands of people building objects in the image
and programming them.  All MOO code runs setuid to the person who wrote the
code.  That means in general, you can't stomp on other people's objects and
properties, especially not accidentally.

Just adding ownership information to objects is not sufficient.  A lot of
knowledge about authorization and trust ends up spread all over the image,
especially without good language support.

The easiest example of this is collection mutability.  Let's say I have a
Set of cool people on my object.  I naively write an getter that returns a
reference.  You add Bill Gates, Steve Jobs, and yourself to the Set I
returned to you, and now my object's behavior is not what I originally
intended.  :-)  What I should have done was clone any mutable object that
could escape from my thread of control before returning it.  Or, I use some
subclass of Set that always checks to see if the caller is me before
mutating---that places the burden of cloning on people asking me for stuff.
Neither of these situations is much fun to explain to the casual user.  Not
very Squeak-y.

MOO takes a cheap way out of this mutability problem---all values (like
lists and strings) are immutable; slots on objects are protected with
explicit permissions.  There's syntactic sugar for  "l[2] = 7" => "l =
listset(l, 2, 7)".

Immutability is implemented through copy-on-write, using ref counts.  Ref
counting on lists does not fail due to cycles because there are no
cycles---there's no way of mutating a list, so there's no way of putting a
reference to itself in.  Objects are always accessed through weak refs, and
allocated and recycled explicitly.

One thing Smalltalk and MOO share for sure is: "gosh, I know that somewhere
in the image is some code that does what I want---now how do I find it...."
MOO's browsing tools are inferior to Smalltalk's, so everything I said about
"hard to find what's important about an object" applies double to MOO.  I've
written a simple MOO client for Squeak, with support for MCP (a structured
out-of-band message protocol).  I've got a simple browser up and running,
and hope to build Whisker for MOO.

Code-sharing in the MOO community seems low.  Maybe there's something about
world image systems that makes this more painful than distributing
patches/CVS for static languages?

I keep on doing designs for a multiprogrammer Squeak and tearing them up.
Maybe I'll get there someday.  I should go reread Lex's sandboxing
proposals.

Jay