Subject: Re: Distributing New Cores, Object Numbers

From: Ken Schalk <[email-masked]>
Date: Mon, 8 Nov 1993 13:56:43 -0800

> Date: 	Fri, 5 Nov 1993 09:39:54 PST
> From: Steven Owens <[email-masked]>
> Subject: Distributing New Cores, Object Numbers
> To: [email-masked]
> 
> [...]
> 
> This seems like such a simple solution, I have to feel I'm missing
> something.  So what is it?

The problem that I see with the scheme you suggest is the implicit
assumption that 2000 objects would be `enough' for any future
potential core release.  I find that to be a big assumption to
swallow.  I don't think that I'd even say that tonum(max_object()) on
Lambda would be big enough.

You may think that I'm being nit-picky here, but believe me, putting
such arbitrary restrictions on a system is just a Bad Idea (tm).  For
anyone who doesn't believe me, think back to the early days of the IBM
PCs, and remember that at one time, due to their weird segmented
memory model, you couldn't create a single contiguous data structure
larger than 64k (at least not without considerable bleeding on the
part of the programmer).  At the time the people at Intel put that
kind of restriction on the original 8088 processor, I'm sure they said
to themselves "Surely 64k will be much bigger than anyone will ever
want to put a single data structure in."  Well, they were wrong (as
many programmers found out and were much frustrated by, myself
included).  Systems grow, much faster and much further than we
imagine.

Saying that 2000 objects will be `big enough,' makes me extremely
wary.  In fact, if you named any number that I think I might be able
to count up to within a week I'd probably still say that chances are
it would one day not be big enough.  Solutions of this kind seem
incredibly simple because they are.  They will also break down
eventually.  What's needed is a more general solution that doesn't put
any artificial and/or uneccessary constraints on the
users(/programmers/wizards).

P.S. I'm not saying that I have a good solution, just that I don't
think this is one.

P.P.S. My reasoning above stems from a piece of what I like to call
'computer philosophy' which I call 'The Rule of 1 or N'.  If you're
interested in a greater explanation of what the heck I'm talking
about, mail me (either INet or MOO).

--Xorian @ LambdaMOO

////////////////////////////////////////////////////////////////////
\\ Kenneth C Schalk \\\\\"Is consciousness just a special form of \\  //-\
/////////////////////////  hallucination?" -- Frank Herbert       // //-O|
\\ [email-masked] \\\\\\"We're each other fragments...but each   \\ |   |
// [email-masked] // fragment reveals the [whole] from a     //  \_/
\\ [email-masked] \\\\\\\\\ different angle..." -- William Gibson   \\
////////////////////////////////////////////////////////////////////

---

From: Steven Owens <[email-masked]>
Date: Mon, 8 Nov 1993 16:01:36 -0800

I suggested reserving the first 3000 object numbers for core objects, to
make core distribution, updates, and management easier.

> Lambda would be big enough.

Somebody also mentioned the problem that it wouldn't help MOOs already
in progress.

Both problems seem to be using the wrong frame of reference, the one an
overly long view, the other an overly short view.  Yes, the true solution
would be to fix the dependence on object numbers; but who's going to fix
it?  And when?

Taking the overly long view of "Well, someday somebody will fix it
right, and meanwhile this solution, though simple, will eventually
become obsolete, so why switch to it?" doesn't help the situation.

Taking the overly short view of "There are already several MOOs set
up that would not benefit from this solution" is equally useless;
you have to start somewhere, and if you don't start sooner you just
have to start later - and now there's even more stuff on the existing
MOOs to update, and more existing MOOs.

What's the "right" way to fix it?  I'm sure there are a lot of
software engineers and programmers out there who know the theory and
background to critically analyze the problem; me, I'm just a writer
with a knack for programming and some bright ideas. I would assume
that a better solution would be to hide the object numbers from most
code.  Should this be done in server or in DB?  And how?

It seems obvious to me that there should be some mechanism more
elegant than object numbers to define parentage and so forth; the only
analogous situation I can think of is writing a C program where you're
explicitly addressing functions and data structures by hardcoded
numerical locations in memory.  Not terribly portable.

But what's the best solution?  Best being defined both by feasibility
(programming time resources to implement the solution, and the memory
and CPU of the average machine running MOO) and elegance.

Steven J. Owens
[email-masked]

p.s. To the person who responded that 3000 objects is 6 meg - you don't
need to reserve 3000 OBJECTS, just 3000 object NUMBERS.  No problem at
all.

> about, mail me (either INet or MOO).

Sure, drop me a line at the address above, I'm interested in what
you're thinking.

---