<HEAD><TITLE>discuss@charon: [720] in "Coldmud discussion meeting"</TITLE>
<H1>[720] in Coldmud discussion meeting</H1></HEAD>
<A HREF="/"><IMG SRC="/i-d.gif" ALT="root"></A>
<A HREF="?720"><IMG SRC="/i-back.gif" ALT="meeting"></A>
<A HREF="/help.html"><IMG SRC="/i-help.gif" ALT="help"></A>
<A HREF="1"><IMG SRC="/i-first.gif" ALT="first"></A>
<A HREF="718"><IMG SRC="/i-fref.gif" ALT="first in chain"></A>
<A HREF="719"><IMG SRC="/i-pref.gif" ALT="previous in chain"></A>
<A HREF="719"><IMG SRC="/i-prev.gif" ALT="previous"></A>
<A HREF="721"><IMG SRC="/i-next.gif" ALT="next"></A>
<A HREF="723"><IMG SRC="/i-nref.gif" ALT="next in chain"></A>
<A HREF="723"><IMG SRC="/i-lref.gif" ALT="last in chain"></A>
<A HREF="1641"><IMG SRC="/i-last.gif" ALT="last"></A>
<HR><H2>Re: binary operators</H2>
<H3>daemon@ATHENA.MIT.EDU (Sun Mar 19 23:14:22 1995
)</H3>
<PRE>
Date: Sun, 19 Mar 1995 20:10:46 -0800
To: coldstuff@MIT.EDU
From: jeffpk@netcom.com (Jeff Kesselman)

&gt;My only objection is that none of the experts (like Greg) have commented, as
&gt; far as I can recall. I don't think binary operators are good philosophically
&gt; because they are so low-level, like giving people access to cpu registers
&gt; only not so drastic. If you need to do something with bits you should be
&gt; doing it with lists of ints, I would guess. Of course, this argument dies
&gt; quickly to Brandon's telnet protocol example. Having a bitfield frob is
&gt; gonna be slow and opt_foo = opt_x.or(opt_y.or(opt_z)); does not look at
&gt; all good compared to opt_foo = opt_x | opt_y | opt_z;
&gt;
&gt;I guess I'd kinda like to add a new type, but that seems repulsive to me at
&gt; the same time. I think it would be good for the same reason buffers are
&gt; better than lists of ints, and bad for the reasons of complicating a server
&gt; revered by some for its simplicity.
&gt;
&gt;A bitmap or bitfield type WOULD be handy tho. Maybe what we need is a way to
&gt; extend the server in-db? Something like what Python does (though I haven't
&gt; looked into it in any depth). I think if we could add new types and have
&gt; them operate as efficiently as if they had been coded into the server it
&gt; would stretch the server's usefull lifetime drastically. Then again, I have
&gt; no immediate suggestions on how to do this.

I think these are good ideas. I went with bitops because I saw them as the
least intrusive way to add this to the server.  Maybe a better solution is
a general structured type mechanism that includes sub-byte addressing.  A
packet construction system, if you will.

Does anyone have any good sugegstions for thsi (I think brandon was
playingiwth packets awhile back...)

&gt;
&gt;Alright, here's what I want. For now, go ahead and add the operators as
&gt; proposed. In the future add operator overloading and such to the language,
&gt; like what C++ has.

I agree that his is needed.  I'm not sure that it would address the
bit-field issue by itself, but its a handy feature for building ontop of
whatever we do.

&gt;Also need to make it possible to extend a running server.
&gt; Also need transportable objects (think distribution).

O yeah I agree.  It woudl be very nice to be able to destribute ColdX
"plug-ware" without necessitating the admin meld it into his existing core.

&gt;When we do have server extension, 'someone' should write a bitfield class, as
&gt; well as an arbitrary-precision number class. Am I thinking too far ahead?

Can you describe how you invision this extension facility working? If you
can give a starting spec, maybe we can hash it out and I can implement
it...


Jeff Kesselman


</PRE>
