[MUD-Dev] Re: PDMud thread summary

[Chris Gray]

[Jon A. Lambert:]

 >An OO mud language needn't have any virtual tables.  Virtual 
 >functions and the like are C++ specific.  You do have to settle on an 
 >object format.  Perhaps this might be a better place to start?
 >
 >What properties do we desire a generic object to have?

Good clarification. Lets get back to generalities.

A generic object should have:

    - system-unique identifier of some kind (could be just a DB id).
	Likely not stored inside the object itself - no need.
    - access rights in accordance with whatever security scheme is used
    - ownership indication (if the system has an ownership concept)
    - whatever (if any) other bookkeeping info is needed in order for it
	to be actually used in the system. E.g. perhaps a refcount.

 >See above... the driver's implementation language shouldn't be a 
 >limiting factor in the design.  You should be able to implement the 
 >same glue in C, basic, pascal, C++, Java, Ada, etc.  Much of 
 >the stuff I've been reading here (although very interesting and 
 >amazing) is very,  very C++ and Linux platform dependent.

Agreed. The details of what we have been suggesting with dlopen and
dlsym are OK, however. That same functionality can be obtained on
WIN32 using LoadLibrary and FindProcAddress. I'd be very surprised if
OS/2 didn't offer something similar. AmigaOS has a Load call, but you
can't find symbols from it. Dunno about Macs. AIX doesn't have dlopen
and dlsym as native (it has load, loadquery and loadbind, but I recall
it has dlopen and dlsym built on top of those). Can't recall about
HP-UX - we haven't had to try that at work (yet!). Solaris has dlopen
and dlsym.

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA