dworkin
Suggestion: rename_object()
This one's just a suggestion. While probably not necessary on non-persistent servers (you could handle it across reboots), there's currently no way to rename objects on persistent servers short of destructing and recompiling them.
This isn't always impossible or even difficult to do seamlessly (it can be easy enough to write some functions to transfer data from one plain object to another), it's certainly not currently possible to do programmatically.
Hence: rename_object(). This kfun would either rename a given object to a new name, or throw an error if the new name is already taken.
Kernels could implement this as part of their mv wiz command, or have a separate command.
DGD used to have support for it very early on, it was used by LPMOO. It wasn't exactly rename_object but part of something called 'virtual objects'.
I later removed it as something that should be simulated in LPC, and that is still the advice I'd give you.
I'm honestly curious the rationale for this.
I'm very likely to implement this locally if there's not a strong reason not to, because not being able to do this has been a nightmare, and I don't see any benefit of creating a whole simulation layer for object names when renaming them is a rare administrative task.
I'd actually like to point out that the immutability of an object name has actually been part of DGD's api for a good while now, as has the fact that clones are just pointers to a master with their own copy of the variable space.
Changing it at this point would be incompatible with present behavior.
Accordingly, there are many mudlibs by now, mine included, that depend on DGD continuing to follow the status quo.
DGD evolving over time is a good thing but breaking backward compatibility is another story entirely.
Names aren't immutable though. Once you destruct an object, another object may take that name, and until one does, it goes unused.
How are you relying on that behavior, I wonder?
I'm not sure I agree that backwards compatibility is actually a concern, because DGD already makes it simple to disable any new and unwanted kfuns.
...I think I'm confused what you're getting at.
Do you mean the name of a clone or the name of the master?
Also do inheritables factor into this if they're in a destructed state but still orphaned as a dependency?
As far as I know names are bound to masters on compilation and then have a number tacked on for the clone. DGD only keeps names for the masters as it is and the clones just have their object ID number tacked on with a #
I may not be the only one reading this issue in the future so a little context may make things clearer.
As for disabling kfuns, that changes the API for any mudlibs and is already considered modifying DGD's source code as it is, albeit in standard manners.
In general, tampering with source code voids the original warranty.
Master objects along with any clones they have. I'm aware clones share the name of their master object, and I don't mean to change that limitation.
The main purpose is administrative. For example, DGD defaults to using object names for source file paths, and object names can be used for various administrative purposes, such as determining who has access rights. It can also be used dynamically, e.g. how Cloud Server initializes things by executing functions on usr/XXX/initd if found. It would be nice to be able to change objects' names for these purposes without destructing them.
You don't have to tamper with DGD's source code to disable a kfun. If you don't want anything running the connect kfun, you can just put something like:
static void connect(string address, int port)
{
error("connect has been disabled");
}
It wouldn't give compile-time errors, so it's not quite as nice as it never existing, but it doesn't require changing DGD code.
Incidentally, Cloud Server disables that kfun for all but a single object. Of course, there's a chain of permissions that allows any guest programmer to create an outgoing binary connection by creating their own user object, but they can't use the kfun directly.
You don't have to tamper with DGD's source code to disable a kfun. If you don't want anything running the
connectkfun, you can just put something like:static void connect(string address, int port) { error("connect has been disabled"); }It wouldn't give compile-time errors, so it's not quite as nice as it never existing, but it doesn't require changing DGD code.
Incidentally, Cloud Server disables that kfun for all but a single object. Of course, there's a chain of permissions that allows any guest programmer to create an outgoing binary connection by creating their own user object, but they can't use the kfun directly.
My apologies, I was speaking from the perspective of actually changing the code, what you're apparently doing is actually masking a kfun in the auto object with a stub that raises an exception.
I do feel obligated to point out that the difference is quite important
Master objects along with any clones they have. I'm aware clones share the name of their master object, and I don't mean to change that limitation.
The main purpose is administrative. For example, DGD defaults to using object names for source file paths, and object names can be used for various administrative purposes, such as determining who has access rights. It can also be used dynamically, e.g. how Cloud Server initializes things by executing functions on
usr/XXX/initdif found. It would be nice to be able to change objects' names for these purposes without destructing them.
You can't actually change the name of a master object in DGD and that's the part that would break its API.
Anything above the API is in LPC land, and since you can write your own driver and auto objects, if you want to do anything involving changed names you'll need to have some sort of mapping layer between the abstract names and the concrete names that intercepts anything that handles object names.
You already got a good start on that method though with the "static void connect" example, which, if I guessed the context correctly, is a static function in the auto object, which will mask the kfun with the same name.
I do feel obligated to point out in general that context is VERY important.
The DGD API is a very solid boundary between LPC code and DGD's own source code and I got confused about the two while trying to understand your comments.
I think it might help if you were clearer in the future.
To try to be as clear as possible:
I'd like a kfun added to DGD that accepts a master object and a string, and if the string is a valid and unused object name, that object's name will be changed to the string.
I don't think adding this would break any existing assumptions, because it is possible to logically rename objects already. There is no guarantee a name will point to a particular object. It is merely needlessly difficult.
And even if it does, because DGD allows kfuns to be overridden by the auto object, it's not difficult for a server to simply disable this feature if it were added.
Personally, I'd expect something like Cloud Server would only allow wizards and System to use it. I'd imagine something like mv either implicitly doing it, or rejecting moving in-use object source files and demanding the wizard to instead type mvobj which would move object and source file both.
These kinds of administrative tools are very useful for me. It seems Dworkin is opposed to some of them, but that's fine - DGD is his project, and the fact I'm able to modify the source code to better suit my own needs is enough for me. However, I'll always ask, because it's always nicer if features can be adopted upstream. ^^
Does that clear things up?
I'm honestly curious the rationale for this.
I'm very likely to implement this locally if there's not a strong reason not to, because not being able to do this has been a nightmare, and I don't see any benefit of creating a whole simulation layer for object names when renaming them is a rare administrative task.
Virtual objects allowed you to rename any object, and it was typically used to give a name like "/room/clearing" to "/obj/forest#1234". FluffOS still has virtual objects, LDMud actually has rename_object.
I removed it because I began to see an object's name as a vital part of an object's identity. Inside DGD, it is difficult to deal with an object that's been renamed from a clone to a master object; an extension of the object struct would be required, which I didn't want to commit to. There are also issues with renaming objects that are inherited. Another issue is that an object can have a name that it cannot be found by, when it's been destructed but is still inherited; renaming an object could give it the same name as a destructed object that it inherits from, which would likely create all sorts of issues.
On the LPC side, object names are used for identification, security, whether an object can be instantiated and -- in the case of light-weight objects -- the object type. rename_object would open gaping security holes in anything derived from the original kernel library, including Cloudlib. Note that the kernel library prevents admins from doing dangerous things; renaming objects is definitely dangerous.
If you really want to implement it yourself, I'd recommend the following restrictions:
- (DGD) only master to master
- (DGD) only for objects that are not inherited (easy limitation when inherited objects are not instantiated)
- (DGD) don't allow the new name to be the same as that of an inherited object
- (LPC) either a massive rewrite or accept that you have a bleeding hole at the heart, keep it under lock and key, then throw away the key
P.S. Don't forget that under the terms of DGD's license, you must make your modifications available to anyone who connects to your MUD.