Dynamic Programming Environments

[Jeremy Lowery]

"Terry Reedy" <tjreedy at home.com> wrote in message
news:2SkZ7.353794$5A3.134650549 at news1.rdc2.pa.home.com...
>
> "Jeremy Lowery" <jslowery at hotmail.com> wrote in message
> news:YSdZ7.365347$er5.9107140 at e3500-atl2.usenetserver.com...
> > WARNING: Below is design, implementation, practicality ramble.
> >
> > I've recently been working on a MUD Engine in python, and I've
> noticed a few
> > (woa too few) people on here that are also interested in MUD
> development
>
> I am interested, but currently only passively.
>
> ...
> > - "Class Definitions" would need to be changed at runtime and their
> > "instances" would have to dynamically reflect this change all
> throughout the
> > system.
>
> This is the premise of your ramble, but I do not really get the
> problem and the need for the convoluted solution (way to much to read
> in detail).  What needs to be changed at runtime and why?
>
Basically all class definitions in the entire system (besides the driver
itself).
It would have to change because that is the main goal of such a system.

> The class of an instance can be changed by reassigning to .__class__.
The problem is not changing the __class__ attribute, it is the persistence
of those
class definitions and their management.

> The attributes of a class can also be changed/augmented by assignment
Again, a correlation between source code and bytecode. Simply reloading a
modified class defintion
wouldn't cut it. A lot of AST object manip here is needed and I've yet to
find some really detailed
source code using it. (The Language services section of the reference is ok,
but only introductory).

> (a somewhat unusual feature of python), which instantly affects all
> instances of that class.
>

Well the main problem is not in the changing of the class attributes, but in
the definition of those classes and
their presence in memory. Like I said, class definitions cannot currently be
stored in ZODB, so a reasonable
alternative would be to store them as plain .py files and import them into
the system. For practical reasons, it wouldn't be a good thing to import
them into the local namespace of the driver, and then the problem of mapping
the custom namespace (a.k.a dictionary) into the ZODB so that the class
definitions of the instances stored could be found before they are accessed.
The editing of these methods and their mapping to the source code files is
also a small (but not unconquerable) problem.

> >You could get really messy with this if you wanted to
>
> Which to my my you did, but is it really necessary?
>

Well, it was only messy because I ventured thru mutiple ways of doing it.
The only thing I saw as inheritly messy was the metaclass stuff.

> Terry J. Reedy
>
> PS. Yes, I have played in MUDs, both textual and graphical.
>
>
>