MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Wish-list (!object nums)

(The following post is devoid of object numbers :) )

At 03:53 AM 8/24/96 PDT, "Geoffrey King" <zzgking@dingo.cc.uq.oz.au> wrote:
>The thing that struck me most are object numbers. I think that any 
>need to use them should be removed from the language. Rather it 
>should be possible to use names as object indentifiers.

This is tantamount to saying that pointers and pointer values should be
removed from C/C++.  In C/C++, you never have to see a pointer, in MOO, you
never have to see an object number.  In C++, 'this' is a pointer to the
current object; in MOO, 'this' is a pointer to the current object.  You
assign names to pointers in C/C++ by assigning pointer values to variables
(be they global or be they local), you do the same in MOO via properties on
the system object (or properties on other objects that have an absolute
reference or a relative reference from 'this').

>The Goal:
>1. Reduce reliance on object numbers.

I don't see how this is a big win, since if you are programming in an object
number reliance way, you are programming bad anyway.

<snip>
>2. Unique objects have their names in a global name space, which can 
>be referenced from anywhere.

This is called a 'core reference'.

<snip>
>The Rational:
>I think not using object numbers where possible is so obvious i wont 
>elaborate.

Gosh darn, Gomer, I must be an idiot.  It's not obvious to me.  Of course, I
don't use object numbers when possible, since it's never necessary.  I'm
surprised there are so many people still using the default object matching
that comes with lcore and not making it more robust.

Extended object matching gets rid of it from the command line.  Both JH and
E_MOO (lifted from JH) have :match_type_object matching via ->, as such you
should never see or have to type an object number for most tasks, even
programming ones:

@program $type->file:read
read $player->tef->notes
read ~tef->notes
go ~tef->home
@d ~eru->event:
 (And it's even been added to eval)

And if your matching stack kicks ass:

look Scrytch's notebook
  (assuming Scrytch is carrying a notebook)

Code is a different story, but you should still never have object numbers in
code.

>Making only *some* objects 'global' would not put every object into 
>this global name-space. Rather only generic classes and unique 
>objects would likely be added (maybe players ?).  

This is called a 'core reference'.

>A simple naming convention would also help manage the global namespace 
>clutter.

Doubt it.  Conventions in MOO (and many other areas) are rarely followed.
They are so rarely followed that we had to create a specific place for the
clutter ($local) to keep it off $sys (look at that, I call it $sys, it's
called $system on other moos, and it's called $life_preserver on still other
places!)  Only smart people thinking about what they are doing can "manage"
the global namespace clutter.

<snip>
>It could be implemented as a object flag bit (aka permission bit).
>a = create(p, o);
>would initially set a.global to 0
>Changes to .name would become dependent on the value of .global

This means that name 1) either not allow whitespace for instances where
.global is true, or you'd have to escape all whitespace in code where a
global object's .name contains a space.  No thank you.

.name is for virtual environment settings.  Let's keep it that way.

Andy
Home | Subject Index | Thread Index