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

Some Way To Handle ZScript Classes With The Same Name

Postby Kinsie » Mon Jun 25, 2018 6:18 am

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
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

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

Postby Graf Zahl » Mon Jun 25, 2018 7:36 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Gez » Mon Jun 25, 2018 8:26 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

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

Postby The Zombie Killer » Tue Jul 17, 2018 7:52 am

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 allExpand view
namespace SomeMod
{
    class A // real name: SomeMod.A
    {
    }
}


Example file B:
Code: Select allExpand view
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 allExpand view
string className = "A";
class classType  = className;


Would be invalid, (classType would be null), but:

Code: Select allExpand view
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
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

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

Postby Graf Zahl » Tue Jul 17, 2018 8:13 am

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
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby The Zombie Killer » Wed Jul 18, 2018 2:10 am

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
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

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

Postby Graf Zahl » Wed Jul 18, 2018 2:15 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Feature Suggestions

Who is online

Users browsing this forum: Dark Pulse and 1 guest