Re: globals considered harmfull.

[I.R.Woollard@bnr.co.uk]

   Resent-Message-Id: <9403221713.AA08568@otis.Stanford.EDU>
   From: Brook Conner <dbc@cs.brown.edu>
   Date: Tue, 22 Mar 1994 12:11:31 +0500
   References: <9403221629.10623@bhl3s1.bnr.co.uk>
   Content-Length: 2467
   Resent-To: real-self-interest@otis.Stanford.EDU
   Resent-Date: Tue, 22 Mar 94 9:13:06 PST
   Resent-From: Urs Hoelzle <urs@otis.stanford.edu>

   I. R. Woollard writes:
    > Self Style Suggestion:
    > 
    > If I want to produce an instance of something, I believe it is better
    > to ask the traits object for it.

   Only if you're following the class-instance model.  Suppose you have
   objects that don't have a traits object?  E.g. all the oddballs?

Yes, if an object has no trait that describes it, (e.g. most traits
objects themselves!) But you generally only want 1 of each of
those. In which case no copying/creating required. But if you want
more than one of a non trivial type of object, I claim it is bad style
*not* to have a traits object for it. (sorry but, oddballs usually do
have traits don't they?)

   What's wrong with providing a prototype that understands a
   copyWith:And:Etc: message?

Reuse is harder. Or, if you mean to put the copyWith... in a trait
then it effectively becomes no different to "new" with a different
name.

    > - a lot of traits already have a prototype slot

   And _all_ the prototypes have traits slots.  A prototype can't
   function without a traits slot, whereas a traits _can_ function
   without a prototype slot.  Don't require unnecessary slots in traits
   objects -- that's violating the "minimal but sufficient" design rule
   (the minimal part).

Disagree. You don't need a globals slot to point to the prototype. You
only need a slot in the traits objects to point to or find the
prototypes. Self currently has both.

    > - its less code in the clients, you don't have to use explicit "copy"'s

   What's the difference between sending new to the traits object versus
   copy to the prototype?

   traits fooBar new.
   prototypes fooBar copy.

I was wrong, same amount of code. However, it is possible to rearrange
the traits structure to allow: fooBar new. Turn traits into a parent
of lobby, and then each reference to a leaf object of traits back into
a normal reference.

    > Currently:
    > - accidently forgetting the copy is a real screw up, you end up
    > modifying the prototype

   Accidentally forgetting a new would be worse.  When you modify the
   traits object, everything that inherited from that traits object would
   be modified.  When you forget a copy, only the prototype is modified
   -- a much smaller-scale change.

   So using copy is actually _safer_ than using new.

Possibly, but, because the prototype has different slots to the traits
object, a walk-back is very likely. Prototypes always have the same
slots as the copy so with probability 1 you screw up.

   Brook

-Ian

Self *is* awesome, particularly the VM and compiler technology...