# Wish-list (!object nums)

Andrew Bakun (abakun@scinc.com)
Mon, 26 Aug 1996 09:56:21 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    (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