[720] in Coldmud discussion meeting

Re: binary operators

daemon@ATHENA.MIT.EDU (Sun Mar 19 23:14:22 1995 )

Date: Sun, 19 Mar 1995 20:10:46 -0800
To: coldstuff@MIT.EDU
From: jeffpk@netcom.com (Jeff Kesselman)

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

>
>Alright, here's what I want. For now, go ahead and add the operators as
> proposed. In the future add operator overloading and such to the language,
> 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.

>Also need to make it possible to extend a running server.
> 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.

>When we do have server extension, 'someone' should write a bitfield class, as
> 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