[self-interest] Re: Nil

[Douglas Atique]

Randall (or Mr. Smith, may I be more informal?),
I have been making small programs in C++ which used the Standard Library
collections,
in which I represented both "undefined" and "non-existent" contained objects
with NULL. I have also read some article about dropping the NULL and using a
NullObject class in place of it, but it seemed cumbersome to have an object
instantiated just for that. Objects seemed just too expensive to "throw away"
like that. Now I am changing my mind about the efficiency concerns vs. ease of
programming and clearness of representation. It's because in Self one thinks
in terms of objects only and not in terms of classes or data. So one can only
worry about an object if it exists. nil itself is an object and can have
slots.But the problem of confusing types continues to exist because nil is one
object, likely to be used in many different places. Perhaps, if a specialized
nil object could have two parents, one would be the common parent of the
objects whose absence that nil represents, the other could be the nil
prototype. In fact, it seems that nothing is due to belong to all nil's but
the fact that they all represent absence of undefinedness.
See comments below.
Regards,
Douglas

Randall.Smith at Eng.Sun.COM wrote:

> Douglas, I think you get the basic idea, and your own refinement of
> having a common nil-like parent is kind of interesting. Though the
> behavior shared by these "not yet specified" or nil-like objects is
> curiously hard to articulate. I mean, what is the essence of vagueness?

I have learned at school that one cannot sum oranges and bananas. But if you
have a collection of oranges and another of bananas, and some of them are not
in the collection, one can represent them with nil, meaning the nil-fruit.
What would this nil-fruit be like, to be regarded as a banana and also as an
orange? No way. I don't see commonality in different nil's. If we have a
nil-banana and a nil-orange and each represents the absence of the
corresponding fruit, then in a collection of bananas we could treat the
nil-banana as a banana (either an undefined or an absent banana) and in a
mixed collection we could know if the place occupied by one of these
nil-fruits is a place for bananas or for oranges.

>
> If you can come up with something, implement it, use it, and extract a
> lesson or two, it might be an interesting OOPSLA paper.
>
> (In my opinion!)
>

This could travel far away through a highly-mathematical/ -logical path. I
don't feel confident to try it. It is really difficult to think about
commonality of objects that represent the absence of other objects. I am not
sure about this essence of vagueness.
Perhaps these objects could be a place to do error handling, or to provide
behavior only available when something is absent, I don't know exactly. I
don't think nil-like objects would have some common state (in the form of data
slots), unless for an implementation detail. Anyway, I just felt that the
traits and common behavior for nil was missing in Self.

>
>         --Randy
>
> >
> > Remember that discussion on the usefulness of nil and the default
> > initialization of slots? I was reading the Self 4.0 Programmer´s
> > Reference Manual this weekend and thought a little bit more about the
> > purpose of nil. If I got the idea, nil should not be used as a default
> > initializer, instead a specific object should be created to mean "no
> > object here" in the particular context. Well, perhaps (I don't remember
> > if anyone said this) nil could be used as a prototype of this kind of
> > object, or a traits, so that the common behavior of all "null" objects
> > would be concentrated on it.
> > Is it already so?
> > I understand that nil is one object, and as such it has one type. So if
> > one uses it to represent "no object" in places where different types are
> > being represented, then one is losing type information. If we create
> > other objects to play this role, so that nil is their parent, or so that
> > they are cloned from nil, perhaps we can keep the commonality of the nil
> > "family" and also keep different nil's for different "types".
> > Did I get the idea, folks?
> > Do I make a point?
> >
> > Douglas
> >
> >
> >
> > ------------------------------------------------------------------------
> > GET $10 OFF ANY ORDER @ healthshop.com! No min. purchase req.
> > Save on vitamins & supplements. Use coupon code: EGROUPS at checkout
> > http://clickhere.egroups.com/click/432
> >
> >
> > eGroups.com home: http://www.egroups.com/group/self-interest
> > http://www.egroups.com - Simplifying group communications
> >
> >
> >
> >
>
> ------------------------------------------------------------------------
> FreeShop is the #1 place for free and trial offers and great deals!
> Try something new and find out how you could win two round-trip tickets
> anywhere in the U.S.! http://clickhere.egroups.com/click/368
>
> 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