<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: DevMUD - thoughts.1 --> <!--X-From-R13: Quevf Uenl <ptNnzv-pt.UenlEntr.Sqzbagba.OP.QO> --> <!--X-Date: Sun, 25 Oct 1998 09:24:17 -0800 --> <!--X-Message-Id: 199810251722.KAA02850@ami-cg.GraySage.Edmonton.AB.CA --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: DevMUD - thoughts.1</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00490.html">Previous</a> | <a href="msg00492.html">Next</a> ] Thread: [ <a href="msg00489.html">Previous</a> | <a href="msg00497.html">Next</a> ] Index: [ <A HREF="author.html#00491">Author</A> | <A HREF="#00491">Date</A> | <A HREF="thread.html#00491">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: DevMUD - thoughts.1</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: DevMUD - thoughts.1</LI> <LI><em>From</em>: Chris Gray <<A HREF="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</A>></LI> <LI><em>Date</em>: Sun, 25 Oct 1998 10:22:00 -0700</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> [James Wilson:] >Though I'm usually a big strong-typing partisan (I've been burned enough >times at work by subtle Perl and Scheme bugs that would have been caught >with strong typing) I'd like to see a _truly_ dynamic type system, in >which an object's type can change dynamically over time. Then adding a >new capability to an object (such as a new magical power) can be done at >runtime. This could be implemented on top of a strongly-typed system >in exactly the same way Scheme is implemented in C. Adding things at run-time (new properties ("class members"), new actions ("class methods")) is not incompatible with a strongly typed language. You just have to have the right view of things, and not be glued to the conventions that C++ and Java use. My MUD language is strongly typed, but I can do this at run time (in wizard mode): (Warning: 'private' does not mean what it does in C++ - it just says who can see the newly defined *symbol*.) private newProperty CreateIntProp()$ Me()@newProperty := 12; private appleEater CreateActionProp()$ private proc eatGreenApple(thing theApple)void: Print("Ugh! That apple is horrible!\n"); reduceHealth(Me(), theApple@sourness); corp; Me()@appleEater := eatGreenApple$ /* Here is the key - the one break from strong typing: */ call(Me()@appleEater, void)(theGreenApple)$ /* That causes run-time checks that the retrieved function returns void, and accepts one parameter matching the type of 'theGreenApple'. */ The system is strongly typed in terms of variables, function parameters, assignments, operators, etc. However, the database entities are completely flexible - they can be modified at will. >I think this is an important feature which should be retained if at all >possible. It would allow a builder to try out some code in the interpreter, >do some rapid development, and, once things are working, have the >interpreted stuff compiled to native code. Moreover, if one is doing funky >graphics or what have you, the extra performance could be a necessity. I don't disagree. In my system, the very nature of the parser requires going from compiled code to interpreted code to compiled code to intepreted code (and possibly more) to handle nearly any input. What I'm trying to avoid is requiring extra overhead for native => native calls across module boundaries. That may not be important, but avoiding it gives us more flexibility in what can be put into a module. Perhaps when a module exports something, it can choose to export two variants, one which uses native linkage, and one which uses interpreted linkage. The core then uses native => native whenever both modules have that available. >I'm trying to understand, so let me ask if this example is something along >your lines: > >Module 'web_support' is set up to work using an external resource >'g_net' which is some subclass of interface 'net_manager'. When 'web_support' >is loaded, it needs to find 'g_net' (i.e. resolve its external reference). >It asks some broker to give it 'g_net'. (There can be multiple specialized >brokers, or one huge one.) The broker determines if 'g_net' is currently >available, and if not tries to find a module which claims to provide it. >Assuming said module is found, it is loaded and the symbol is provided to >'web_support'. That's a sort-of valid example, I think. I hadn't thought about the idea of somehow automatically loading modules to resolve undefined references. I was more concentrating on how explictly loaded modules would be tied together. If we use 'dlopen' for loading, would a load module needed by another be automatically loaded by dlopen? How would *our* loader know that a given module exports a 'g_net' before someone has loaded that module? I had thought that we wanted the various modules to be compiled completely independently of one-another. The only header file I had envisioned for inter-module stuff was one that defined constants for all of the currently existing interface kinds, and provides prototypes for that kind. >the issue of 'what goes into a module' is quite different from 'what should >be a thread'. Module 'web_support' could simply provide a set of functions >and classes for other modules to use, if they want. There is no need for a >thread there (although the underlying network functionality might well be >threaded). On the other hand, one might conceivably want a weather module >to start up a weather daemon thread when it loads (or multiple threads). >Depending on the event model, this might not make sense. (i.e. perhaps >all these modules do is provide types of events and event contexts, and >the threading strategy is chosen by the engine.) I agree. That's what I was trying to say. >> void inputHandler(void *source, uint kind, void *data, ulong len) > >right here is where the C++ goons come and break your kneecaps. Ooh. Ouch! :-) >Using a >straight function call doesn't allow someone to write a handler which >has its own individual state, e.g. > >static string s_magic; > >void inputHandler (/* rep */) >{ > // manipulate s_magic in a non-reentrant way >} > >is BAD in a multi-threaded environment (and inflexible in any case). The >alternative is quite appealing: > >struct input_handler >{ > virtual void handle (/* rep */) = 0; >}; > >can be specialized to be thread-safe and have any state it likes: > >struct my_input_handler >{ > virtual void handle (/* rep */) > { /* magic */ } >private: > string _magic; > mutex _lock; >}; I understand the C++ syntax you have written (except for "/* rep */" - is that just meant to copy the prototype?), but I'm completely failing to see what you are getting at. Sorry. Why would a handler want state? It seems to me that in a persistent virtual world, all state should either be attached to the entity (e.g. player character) doing the action, or be global state attached to some other persistent entity in the virtual world. In either case, the preserving and retrieval of that state have to go through the system's database. There should be very little static state in any modules, and that all has to be protected by mutex's or spinlocks. Or, the module could use queuing to serialize accesses. An example of static state would be the set of client sockets that a telnet input module would maintain. >IMO, interfaces should be up to the module programmers. Think of a module >as a shared library; to use that shared library, you write a program that >#includes the proper headers, and link it against libfoo.so. It's up to >you to use libfoo's api according to the headers, and up to the compiler >to check your errors. If you want to write a new module with some funky >interface, and Bob wants to use said funky interface, that should be as >easy as #including your headers and linking against your library (or >whatever analogue applies). If some modules wish to use shared libraries, that is up to them. 'dlopen' can take care of that. It is outside our concern. What I think we need is ways whereby, e.g. modules that provide user input/output to the system can be linked up to modules that provide parsing, scenario code, and database operations. That linking up isn't done by name, it is done based on the semantic nature of what is needed. Hmm. I suppose you could use names to indicate that semantic nature. E.g. any module that exported a parser would export a public symbol called 'parse', and the dlsym facilities could be used to find that at run-time, and connect to it from an input provider. However, that is just replacing the set of constants in a header file with a set of strings, which would likely also be in the header file beside the prototypes needed. In this scheme of the header file containing the prototypes for the interface kinds, it is quite easy to add new interface kinds. By definition, no module is using or exporting an interface kind before that interface kind is defined. OK, so someone needs a new one. They add it to the big header file, along with the prototype they intend for it. New modules can now be written that communicate using that new interface kind. Old modules, which by definition do not use the new kind, are not affected. Similar if someone wants old modules to use the new kind - they must be modified to use it, and all is still well. WOLOG (one of my math profs used that: WithOut Loss Of Generality). There is no particular reason that the "one big header file" couldn't be split up into smaller pieces, if there are specialized interfaces that only a couple of modules need. However, there does need to be some mechanism (Perl scripts?) to check that no interface kind ID (whether a number or a name) is used more than once. We don't want a parser calling a database's 'fixup' interface when it is supposed to be calling an output filter's 'fixup' interface. James, it seems to me you are thinking of building modules that are aware of each other at compile time. I've been trying to avoid that, so that only at run-time are they actually attached to one-another. But then, I could be missing your point altogether. How about a more detailed example? Please, someone jump on me if I'm coming on too strong here. I'm not trying to squelch anyone else's ideas and proposals. I'm just espousing some thoughts I've had. -- Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00497" HREF="msg00497.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></strong> <ul compact><li><em>From:</em> James Wilson <jwilson#rochester,rr.com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00490.html">[MUD-Dev] Re: MUD verb handling (Was: DevMUD - thoughts.1)</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00492.html">[MUD-Dev] Re: PDMud thread summary</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00489.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00497.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00491"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00491"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: openmud or pdmud or devmud</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00528" HREF="msg00528.html">[MUD-Dev] Re: openmud or pdmud or devmud</A></strong>, Bruce Mitchener, Jr. <a href="mailto:bruce#puremagic,com">bruce#puremagic,com</a>, Tue 27 Oct 1998, 01:49 GMT <UL> <LI><strong><A NAME="00530" HREF="msg00530.html">[MUD-Dev] Re: openmud or pdmud or devmud</A></strong>, Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Tue 27 Oct 1998, 02:24 GMT </LI> </UL> </LI> </ul> </LI> <LI><strong><A NAME="00490" HREF="msg00490.html">[MUD-Dev] Re: MUD verb handling (Was: DevMUD - thoughts.1)</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 16:25 GMT <LI><strong><A NAME="00489" HREF="msg00489.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 16:16 GMT <UL> <li><Possible follow-up(s)><br> <LI><strong><A NAME="00491" HREF="msg00491.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 17:24 GMT <UL> <LI><strong><A NAME="00497" HREF="msg00497.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></strong>, James Wilson <a href="mailto:jwilson#rochester,rr.com">jwilson#rochester,rr.com</a>, Sun 25 Oct 1998, 20:45 GMT </LI> </UL> </LI> <LI><strong><A NAME="00500" HREF="msg00500.html">[MUD-Dev] Re: DevMUD - thoughts.1</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 22:38 GMT </LI> </UL> </LI> <LI><strong><A NAME="00488" HREF="msg00488.html">[MUD-Dev] Re: OpenMUD: bus-based communications</A></strong>, Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Sun 25 Oct 1998, 16:03 GMT <UL> <LI><strong><A NAME="00496" HREF="msg00496.html">[MUD-Dev] Re: OpenMUD: bus-based communications</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Sun 25 Oct 1998, 19:52 GMT </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>