[self-interest] Re: data structures

Randy Smith Randall.Smith at Eng.Sun.COM
Fri Jun 11 17:21:33 UTC 1999 

Okay let me try a concrete example of how you could improve on nil.

Suppose you had an object that represented the concept of an
not-yet-defined number. An uncertain numerical quantity.

It could respond to messags like "squareRoot" by returning
a copy of itself, because the squareRoot of an uncertain thing
is an uncertain thing. Same with + , *, / , and so on.

It could print itself as "an undefined number"
or whatever.

So: here you are making a bankAccount object. In the currentBalance
slot, you may wish to place an undefined number, to represent the fact
that it is uninitialized. 

bankAccount = (| parent* = traits cloanble.
                 currentBalance <- notYetDefinedNumber copy.
              |)

Then when anyone executes "bankAccount clone," they start off with an
undefined balance.

So far, it is just like using nil. BUT WAIT! The you decide to add this
prinString method to the bankAccount:

printString = (
  'a bank account with balance ' , 
   currentBalance printSting , 
  'which at 10% interest per year will grow to ' ,
  (currentBalance * 1.10 ) printString.
)

Now if the slot had nil in it, crash city! But the 'not-yet-
defined-number' can be multiplied by other numbers, so it is all okay.

The prototype prints as

'a bank account with balance an undefined number which
 at 10% interest per year will grow to an undefined number'

Sorry for the forced example, I'm sure there are better ones.

Dave was also pointing out that arithmetic protocol could be extended with
conditionals to allow test like this:

  foo ifUndefinedNumber: [ ... ] Else: [ ... ]

To avoid the

  foo = nil ifFalse: [ ]

though I guess the savings here is not that big a deal.

In general case the VM still has to put something in slots
when the programmer writes

  (| a. b. c. |)

So maybe that could be made ilegal. (?)


	--Randy


> From self-interest-return-214-Randall.Smith=Eng.Sun.COM at returns.egroups.com Fri Jun 11 05:07 PDT 1999
> Mailing-List: contact self-interest-owner at egroups.com
> X-Mailing-List: self-interest at egroups.com
> X-URL: http://www.egroups.com/list/self-interest/
> Delivered-To: listsaver-egroups-self-interest at egroups.com
> Date: Fri, 11 Jun 1999 09:09:37 -0300
> From: Douglas Atique <datique at alcatel.com.br>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: self-interest at egroups.com
> Subject: [self-interest] Re: data structures
> Content-Transfer-Encoding: 7bit
> 
> Huh? I didn't understand... See my comments below.
> Regards,
> Douglas
> 
> David.Ungar at Eng.Sun.COM wrote:
> 
> > Amen!
> >
> > When designing Self
> > I came to believe (and still do) that the idea of 'nil' is not
> > object-oriented at all.
> 
> Why isn't it object-oriented? I've always understood nil (or NULL, or null) as
> "nothing", "no object". If I say "What object is pointed to by this slot?" and the
> answer is "no one" then it seems right that nil is there. I thought nil was
> necessary to have some value or some object to indicate this absence. In C++, for
> instance, the conceptual nil object (which is at adress 0, aliased NULL, right?)
> exists as some object whose address is 0x00000000. If the implementation cares
> about it (and I think they all must care) there should be no real object or
> variable at address 0, so that no real object can have the same address as NULL.
> Then, why not think the memory at address 0 contains an object? I am used to fake
> to myself that there is a system-defined object there named NULL, whose address is
> 0 (but could be any other address) and it seems conceptually clean. Many algorithms
> I have implemented take into account that a pointer containing NULL refers to
> "nothing", meaning that none of the objects that interest the algorithm is there.
> If we come to the implementation side (pardon me again :-) we can't avoid to
> consider that every reference to an object is implemented as a pointer, that is, as
> a memory location whose value is an address. So how do you say "This slot doesn't
> point to anything" ? Leave it with a random value? This seems dangerous, as you can
> always coincidently refer to an existing object, or to garbage (which can be part
> of an object's memory). Don't we need the concept of "no object"? Could you please
> explain this again?
> 
> >
> > It is just a holdover from Lisp via Smalltalk.
> > If I had to do it all over again, there would be no nil in Self.
> >
> > (So why? Because 'nil' is the same no matter what kind of object
> > isn't there. This leads to code such as:
> >
> > nil = foo ifFalse: [
> >     <do something with foo>
> > ]
> >
> > If instead, you make a special object that respects the right
> > protocol you could write
> >
> > foo doSomething
> >
> > or
> >
> > foo doSomethingIfNotInitialized: [...]
> >
> > - Dave
> >
> > PS: I'm not sure my messages are reaching the alias--could someone verify?
> 
> You mean self-interest at egroups.com? I got your message from there.
> 
> >
> >
> > At 3:48 AM -0300 6/9/99, Jecel Assumpcao Jr wrote:
> > >Ian Trudel wrote:
> > >> : In Smalltalk we would do "vector new: 3" since everything is
> > >> : initialized with nil, but Self doesn't like defaults and so you
> > >> : have to choose some initial value (like 0 in this example)
> > >> : explicitly.
> > >>
> > >> Out of interest, why Self doesn't like defaults? Time consuming? Personnaly,
> > >> I prefer everything has a default value before uses. Maybe just because I
> > >> am, and every programmer I know, are human and sometimes forgot to
> > >> initialize.
> > >
> > >Self is based on prototypes instead of classes. A class includes,
> > >among many other things, a plan to build object instances of itself.
> > >This plan (the #new method in Smalltalk, the constructor in other
> > >languages) will normally replace any defaults that the system uses
> > >when allocating the instance with values that are appropriate for
> > >that class.
> > >
> > >A prototype, on the other hand, is usually "hand made". It can be
> > >cloned to generate new "instances", but it is an actual working
> > >"instance" itself and its slot values should reflect this. We could
> > >have a Record class in Smalltalk with this creation method:
> > >
> > >   new
> > >   "creates an initialized Record object"
> > >   ^ self basicNew initialize
> > >
> > >where the instance method is:
> > >
> > >   initialize
> > >   "sets the initial values for the Record object"
> > >   name := 'unnamed'.
> > >   age := 0.
> > >   ^ self
> > >
> > >We could do the exact same thing in Self, of course:
> > >
> > >   (| parent* = traits clonable.
> > >      name.
> > >      age.
> > >      copy = ("creates a new initialized record"
> > >              resend.copy initialize).
> > >      initialize = ("sets the initial values"
> > >                    name: 'unnamed'.
> > >                    age: 0.
> > >                    self)
> > >   |)
> > >
> > >but a the following would be much more Selfish:
> > >
> > >   (| parent* = traits clonable.
> > >      name <- 'unnamed'.
> > >      age <- 0
> > >   |)
> > >
> > >In the first Self example, the slot values for the prototype are
> > >the default (nil). They are a string and an integer for every
> > >object clones from the prototype, however, so the prototype is not
> > >a true representative of this kind of object. The second example
> > >fixes this, but is now subject to the "prototype corruption
> > >problem". That is when you change the prototype itself instead of
> > >a copy (by sending it the message 'age: 10', for example). This
> > >will effect every new clone created in the future.
> > >
> > >So what I should have said in my comment what that in Self we should
> > >always avoid depending on defaults like nil but should instead create
> > >the prototypes with the right types of values (which are another kind
> > >of defaults, of course).
> > >
> > >-- Jecel
> > >
> > >
> > >------------------------------------------------------------------------
> > >Explore the Web for sites in Science & Technology from Looksmart!
> > >http://clickhere.egroups.com/click/302
> > >
> > >
> > >eGroups.com home: http://www.egroups.com/group/self-interest
> > >http://www.egroups.com - Simplifying group communications
> >
> >
> >
> >      David Ungar
> >      Sun Microsystems Laboratories
> >      (650) 336-2618
> >
> > ------------------------------------------------------------------------
> > Track your stocks and funds in a StockMaster portfolio. With easy setup,
> > you get quotes, charts, and news for them all on just one page. No
> > limits, fast loading, and FREE!http://clickhere.egroups.com/click/238
> >
> > eGroups.com home: http://www.egroups.com/group/self-interest
> > http://www.egroups.com - Simplifying group communications
> 
> 
> ------------------------------------------------------------------------
> Track your stocks and funds in a StockMaster portfolio. With easy setup,
> you get quotes, charts, and news for them all on just one page. No 
> limits, fast loading, and FREE!http://clickhere.egroups.com/click/238
> 
> 
> eGroups.com home: http://www.egroups.com/group/self-interest
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 
> 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications

More information about the Self-interest mailing list