[MUD-Dev] I wanna do it OO

[James Wilson]

On Sat, 24 Oct 1998, Chris Gray wrote:
>[ApplePiMan:]
>
> >>(Small voice: I still want to do it O-O. Wanto! Wanto!!! :)
> >
> >Did I miss something? I didn't think any decision had been made on that 
> >yet...
>
>If it did go by, I missed it too! I've been muttering about deciding
>what an appropriate object model for the MUD DB might be, but I sure
>haven't said there shouldn't be one. I think I've also said that we
>should think about whether the DB object model needs to be the same
>as any object model that might be used in the implementation language.
>I've also said I don't think much about the in-MUD language being a
>subset of C++. Perhaps some of these were misconstrued?

I thought the best idea was to do it like MUQ, and have some sort
of internal representation which could be interpreted or compiled to 
native code (perhaps via C or C++), which would have to interoperate
transparently  with the interpreter... then (assuming the internal
representation and underlying semantics are flexible enough) one could 
write compilers for different mud languages, converting them into said
representation. I should think that the representation would be pretty
high-level for efficiency. (It worked for the VAX, right? Oh, wait...)

For those who like bytecode as an internal representation, I would like 
to note that using 'interpreted objects' rather than bytecode can be quite 
speedy. By this I mean that, for instance, a while loop can be represented
as 

struct while_exp : public expression
{
	virtual rep eval (vector<rep> &stack)
	{
		while (_test->eval (stack))
		_action->eval (stack);
		return VOID_REP;
	}
....
private:
	expression *_test, *_action;
};

this sort of internal representation is also really easy to integrate
hand-written (or automagically-generated) C/C++ code with, as opposed to
bytecode which doesn't have such a straightforward binding.

James