Some Way To Handle ZScript Classes With The Same Name

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

User avatar
Kinsie
Posts: 7399
Joined: Fri Oct 22, 2004 9:22 am
Graphics Processor: nVidia with Vulkan support
Location: MAP33
Contact:

Some Way To Handle ZScript Classes With The Same Name

Post by Kinsie »

Currently, ZScript differentiates itself from its sloppier precursor DECORATE by throwing an error if two classes have the same name. This is all well and good, but there are some situations where disabling this behaviour on a per-class basis would be beneficial - for example, libraries and assistant classes that would be advantageous to have embedded within a mod, and that may well be in multiple loaded mods at once due to their usefulness. Some such library developers are experimenting with some fairly clunky workarounds - I believe ZForms currently requires the user to apply a mod-centric prefix to all the classes via a Python "build script" - but I feel like a more graceful solution should in some way be possible.

Exactly what that could be, however, is a big question. Possibly a keyword that tells the engine that it's okay for that actor to be overridden by an actor with the same name later in the load order? There's probably a technical reason why this can't happen, though...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Some Way To Handle ZScript Classes With The Same Name

Post by Graf Zahl »

This was disabled because duplicate class names cause unresolvable problems with internal class maintenance. Namespacing would certainly be nice but the way class name lookup works is plain and simply not possible. It would require some hefty refactoring in critical code.

The only thing I can imagine is to allow optional classes that would be skipped if a same-named class already exists - but that'd nuke all code in it along with the class.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: Some Way To Handle ZScript Classes With The Same Name

Post by Gez »

A stub keyword perhaps?

An actor class marked as a stub would be ignored if a class with the same name (stub or not) already exists. Inversely, if a stub class has already been loaded and a non-stub class with the same name is encountered, then the stub class is purged from memory and the non-stub is loaded instead. Two non-stub classes of the same name would still trigger the error message of course.

This would allow multiple mods to be potentially compatible with each other, while still being able to be used standalone.
User avatar
The Zombie Killer
Posts: 1528
Joined: Thu Jul 14, 2011 12:06 am
Location: Gold Coast, Queensland, Australia

Re: Some Way To Handle ZScript Classes With The Same Name

Post by The Zombie Killer »

Graf Zahl wrote:Namespacing would certainly be nice but the way class name lookup works is plain and simply not possible. It would require some hefty refactoring in critical code.
Could you elaborate on this? Since I can think of plenty of ways to implement namespacing that shouldn't require many changes. For example, say you have this syntax:

Example file A:

Code: Select all

namespace SomeMod
{
    class A // real name: SomeMod.A
    {
    }
}
Example file B:

Code: Select all

import SomeMod;
import AnotherMod;

class B
{
    void Example()
    {
        A a = new("A");
    }
}
Internally, the class lookup should do something like iterate over all class names and see if any match "A". If none match directly, look at all imports currently in scope (SomeMod, AnotherMod) and prepend them, thus doing a second search for SomeMod.A, a third search for AnotherMod.A if that fails, etc...

As for when class names are resolved at runtime, they just simply need to be fully qualified. For example:

Code: Select all

string className = "A";
class classType  = className;
Would be invalid, (classType would be null), but:

Code: Select all

string className = "SomeMod.A";
class classType  = className;
Would work as expected.

(It should be noted that while namespaces solve the issue of name conflicts amongst different mods, it doesn't necessarily solve the problem for libraries, which are often embedded directly. In this case, something akin to what Gez suggested could be used in combination with namespaces.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Some Way To Handle ZScript Classes With The Same Name

Post by Graf Zahl »

The Zombie Killer wrote: Internally, the class lookup should do something like iterate over all class names and see if any match "A". If none match directly, look at all imports currently in scope (SomeMod, AnotherMod) and prepend them, thus doing a second search for SomeMod.A, a third search for AnotherMod.A if that fails, etc...

Feel free to rewrite the internal lookup code to do this. Unfortunately it depends on some quirks that really don't make this simple (and never forget that this is a performance critical piece of the engine.)
User avatar
The Zombie Killer
Posts: 1528
Joined: Thu Jul 14, 2011 12:06 am
Location: Gold Coast, Queensland, Australia

Re: Some Way To Handle ZScript Classes With The Same Name

Post by The Zombie Killer »

Graf Zahl wrote:
The Zombie Killer wrote: Internally, the class lookup should do something like iterate over all class names and see if any match "A". If none match directly, look at all imports currently in scope (SomeMod, AnotherMod) and prepend them, thus doing a second search for SomeMod.A, a third search for AnotherMod.A if that fails, etc...

Feel free to rewrite the internal lookup code to do this. Unfortunately it depends on some quirks that really don't make this simple (and never forget that this is a performance critical piece of the engine.)
If I get some time in the coming months I may give it a shot (at present I'm busy with various other work). Could you clarify what those quirks are? If you're aware of them already then it'd be helpful to know what to watch out for if and when I get around to implementing it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Some Way To Handle ZScript Classes With The Same Name

Post by Graf Zahl »

The main problem is that the class names are stored as FNames. For single names this is relatively fast, but once you have to go back to the string representation and eventually even split that up all the performance optimizations the name type brings will go away.
You will also have to address how this is represented in the VM code.
Overall it will be quite a bit of work to extend the name type to handle namespaced values.
Post Reply

Return to “Feature Suggestions [GZDoom]”