At 02:07 PM 10/9/98 -0700, you wrote:
>In a nutshell, it's simpler.
>
>By simplifying the data-structures of the language, 
>prototype-based languages are able to:
>
>- unify objects, classes and metaclasses
>- unify delegation and inheritance
>- unify state and behavior
>- unify copying and instantiation
>- eliminate programatic initialization
>- eliminate globals

....leaving nothing to serve as design guideposts in the code/model...

>And as a result, the programmer has a much greater degree
>of runtime flexibility. In a proto langage, you can:
>
>- add state(ivars) and behaivor(methods) to specific objects at 
>  runtime without effecting others and then use these as protos(like classes)
>  (which allows you to also dynamically change inheritance of specific 
>  instances at runtime)
>- avoid namespace collision problems
>- isolate programs from the object system that they're running in.
>
>And all sorts of other things become much simpler like:
>
>- persistence
>- object and program migration and distribution across networks
>...

and
- creating an incomprehensible program structure of one-off objects that
  completely hide any design that might have gone into the program.

seriously, as i have posted here before, i would *love* to have a Squeak
that was able to accomodate *both* prototypes and classes, but i don't
really buy into the notion that prototypes are an object panacea.

i have to admit that i have not had much opportunity to use prototypes, but
from what i've heard and read about prototyped systems (the venerable Joe
the Box comes to mind) is that the flexibility of prototypes makes it harder
to enforce the structure needed later on in a large system. the old saying
still rings true: "you don't get something for nothing." my personal
experience has been that i've most wanted the ability to one-off objects at
the begining of a design cycle when i still didn't a firm grasp on what the
final design should look like and what it should do. but as i go through
iterations on the design the class heirarchy *captures* (or should be
capturing) what i am learning about the problem domain. and i think that
prototypes are much less suited to doing the same.

there are all kinds of place that i'd like to prototypes though. i'd love to
be able to open a workspace and do scratch together an object or set of
object instead of being limited to functional programing. (that's long
struck me as one of the biggest ironies of being a Smalltalker: my precious,
indispensable Workspace is a *function* workbench (if we were around
non-object types we would say "method" or "algorithm"), not an *object*
workbench. and then be able to take the prototyped object model and create a
class heirarchy that, again, captures what i've leared about the problem at
hand. i'd also love to be able to break the class guarantee for purposes of
debugging. (Ralph Johnson has advised work in this area that accomplishes
the same thing, but with classes.)

this is, what, the umpteenth time we've gone down this prototype vs class
trail. when is someone going to do something about it? any one got any ideas
about how we could modify/extend squeak to allow experimentation in this area?

dave

--
        j. david farber
    oo architect+mentor
numenor labs incorporated
in sunny boulder colorado
    dfarber at numenor.com
        www.numenor.com