On Fri, 21 Jan 2000, Chris Gilbert wrote:
> One thing I'm presently looking up is to take the editors and work out
> a generic class that all the editors derive from. By the use of
> virtual functions
...or function pointers in a non-C++ frame-work...
> the addition of a new editor could be greatly eased. you just add in
> the new editor, no hacking of interpreter.c oasis.c etc, you just add
> the editor c file and add the info to a struct somewhere.
I've done something _like_ this outside of the CircleMUD framework. It's
not very cleanly implemented in my qServer ("q" standing for "quick",
which is a judgement of the amount of time spent writing it, not its
actual speed) and ANSI C -- I guess gcc 2.95 is further along with C99
support, but until I upgrade from egcs 2.91.66, I'll just use good ol'
ANSI C -- but it works. Basically, it's a series of input shells that get
assigned to the user. The shells can be dynamically linked or static
code compiled directly into it. There are four shell functions,
void xxx_init (connection_t *cn);
void xxx_prompt (connection_t *cn);
void xxx_shell (connection_t *cn, const char *input);
void xxx_deinit (connection_t *cn);
The connection_t object has a 'shellData' void pointer on it for
shell-specific data if the specific shell needs it. A static-linked shell
is registered in the shStaticsRegister() function; dynamic-linked shells
provide,
dllType_t myType = DLL_SHELL;
char *myName = "foobar";
void myInit (connection_t *);
void myPrompt (connection_t *);
void myShell (connection_t *, const char *);
void myDeinit (connection_t *);
and is registered with the shell when it's loaded up and myType is
DLL_SHELL.
> I'm even thinking of working out a way to load in shared objects that
> contain new commands, these can be added and removed on the fly :)
I've also done this (as can be seen, above, since the framework provides
it), demoed to a handful of people along with auto-recognition of terminal
types. Again, not in a CircleMUD framework, but easy enough to
adapt. I've been going through and looking at a lot of my old code; I
might even have a CircleMUD version of it from a year or so ago.
> I'd think most ppl would prefer C++, these days the compilers are
> getting better, g++ 2.95.2 is pretty good (it can manage to compile
> Unreal Tournement up)
I rather like ANSI C and, even more so, C99. Mind you, I've never been a
big fan of C++, I think there's quite a bit wrong with the language which
are better handled in other object oriented languages. It's really a
matter of design and maybe purpose. I dislike the static nature of C++
for object oriented programming, something which languages like Objective
C address in a semi-elegant manner. I don't think static, very strong
typing, which is what C++ is moving more and more towards, is particularly
suitable to the dynamic nature of most objects. C++'s strong typing is
what has given us "templates", which are syntically ugly and _increase_
complexity in programs. I think languages which provide generic list and
vector semantics, such as Python, Perl, and Lisp are much better. At the
same time, I refuse to give any praise to Perl for it being a write-only
language ill-suited for most of the tasks its used for (it's great for
some things, but I'll never understand why someone would want to write
much of anything in it); and functional languages like Lisp and Scheme are
annoying because (a) all those () and backquotes are confusing, and (b)
RPN ... blegh. Python...hmm...I might just like it. Of course, I must
admit a bias for any language with clean syntax and dynamic binding.
Which is part of the reason why I think Objective-C is peachy (but not
great, since it uses C's syntax and I don't think it works, here).
> One of the nicest things I've done is get rid of rnums, I use an index
> class and overide the [] operator. It's so much nicer :) (those
> wondering I took the idea and code from the source of death gates mud)
Global namespaces are very, very stupid and cause many, many problems.
This is obvious: just look at all the problems we have with generic_find()
and get_obj_vis() and the necessity of dot notation for imm commands, etc.
Ugly, ugly, ugly. If we can agree on that, then I think we're one step
closer to the conclusion that a global ID space for *INHERENTLY*
structured data is just as thoroughly idiotic. Consider that items,
rooms, and mobiles are, by their nature, organized into zones and yet we
use a global name- and ID- space for them, with a design kludge in the
IDspace for organizational purposes (that is, (entity->zoneNumber * 100)
is the first vnum for entities in that zone). This is ugly and silly.
> My aim is to tidy up a lot of the code, and then release it out to see
> what ppl think of it, but that'll probably be a few months off on my
> own. (and at the moment it's a mess of ideas)
Shrug. Release now, even if it doesn't work. You might actually get
help in reworking the really ugly parts. As soon I actually have
something to show, I'll release it. But I don't think anyone is
interested in a bunch of echo servers implemented with different IO event
models and threading -- even if they say they really, really are, I won't
believe 'em. ;)
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT