Enum Duplicate Names?

[jredfox]

System.out.println(EnumCreatureType.values());
EnumHelper.addCreatureType("MONSTER", EntitySheep.class, 22, Material.CAKE, false, true);
System.out.println(EnumCreatureType.values());

output:

[17:06:47] [main/INFO] [STDOUT]: [com.EvilNotch.lib.main.MainJava:preinit:108]: [MONSTER, CREATURE, AMBIENT, WATER_CREATURE]

[17:06:47] [main/INFO] [STDOUT]: [com.EvilNotch.lib.main.MainJava:preinit:110]: [MONSTER, CREATURE, AMBIENT, WATER_CREATURE, MONSTER]

How is this possible to have variables with the same two names should I support this or be like nope throw error enum name duplicate for iterating through EnumCreatureTypes
 

Edited April 13, 2018 by jredfox

[Draco18s]

You don't know what EnumHelper does, do you?

[jredfox]

2 minutes ago, Draco18s said:

You don't know what EnumHelper does, do you?

no but, it seems to be adding a duplicate variable name to the enum list. If I did this and tried to compile I would get an error so why no error checks here. This code below will have compile error enums are not meant to have dupe names

	public static enum A{
		a(),
		b(),
		a();
	}

 

Edited April 13, 2018 by jredfox

[Draco18s]

9 minutes ago, jredfox said:

no

Then stop using it. It does not do what you think it does (which is clearly "who knows what")

[jredfox]

3 minutes ago, Draco18s said:

Then stop using it. It does not do what you think it does (which is clearly "who knows what")

I want to find all creature types of the enums but, I don't think there should be dupe variable names

Edited April 13, 2018 by jredfox

[Draco18s]

Well, addCreatureType is definitely not how you examine what the possible values are.

[jredfox]

Just now, Draco18s said:

Well, addCreatureType is definitely not how you examine what the possible values are.

I was testing if dupes are allowed then got really confused when they are

How am I suppose to determine what creature type is what if there is no .equals() and I write them to a file using the toString() as the name of the file. Looking up the enum with that string would always result in the one with the first name and not nessarly one written to the disk.

[jabelar]

This is modding so we are trying to extend an enum after it is already defined in code we may not have scope over. This means that EnumHelper is using Reflection tricks to get the effect, but it also means that the "name" of the enum is actually not really the actual underlying type of the enum. 

 

It is better than nothing, but I suppose it probably does allow apparent duplicates. However, that would certainly be an error. I think they would have to be treated as the same thing. Think about it, if someone extends a CreatureType enum with a duplicate name and then assigns that CreatureType to an entity it would of course assign it to the first one -- in other words, even if you can create duplicate entry I don't think it would ever be actually assigned to anything. That could cause a bug for any mod that did that, but shouldn't be a concern for you.

[Draco18s]

33 minutes ago, jabelar said:

but it also means that the "name" of the enum is actually not really the actual underlying type of the enum. 

Pretty much this. We can't actually tell what's going on under the hood (without reading the code, assuming that we even understand it if we do, and that there isn't additional magic going on deep down in the JVM). We just have to accept that it does what it does in a way that does what we actually want to do.

 

And given what you are trying to do, and what this function actually does, work at cross purposes, you shouldn't use it.

[jredfox]

24 minutes ago, Draco18s said:

Pretty much this. We can't actually tell what's going on under the hood (without reading the code, assuming that we even understand it if we do, and that there isn't additional magic going on deep down in the JVM). We just have to accept that it does what it does in a way that does what we actually want to do.

 

And given what you are trying to do, and what this function actually does, work at cross purposes, you shouldn't use it.

what should I use? For my mod people define new entities from strings for an enumcreature type when then adds a biome list entry based on that creature type? Should I be comparing deep values or just ignore the dupes?

Edited April 13, 2018 by jredfox

[Draco18s]

17 minutes ago, jredfox said:

Should I be comparing deep values

"Huh, I want to know if this object is the same as this other object. Maybe I should compare them."

[jredfox]

2 hours ago, Draco18s said:

"Huh, I want to know if this object is the same as this other object. Maybe I should compare them."

I don't know how else I would do it besides storing the values inside of the same file with same name but, multiple entries in that json and my line library was suppose to be getting away from json for easy configuration and less parsing errors.

[Draco18s]

If you can't figure out how to check one list of items against another list of items and avoid duplicates, I can't help you. You need to go learn basic Java.

[jredfox]

3 hours ago, jabelar said:

This is modding so we are trying to extend an enum after it is already defined in code we may not have scope over. This means that EnumHelper is using Reflection tricks to get the effect, but it also means that the "name" of the enum is actually not really the actual underlying type of the enum. 

 

It is better than nothing, but I suppose it probably does allow apparent duplicates. However, that would certainly be an error. I think they would have to be treated as the same thing. Think about it, if someone extends a CreatureType enum with a duplicate name and then assigns that CreatureType to an entity it would of course assign it to the first one -- in other words, even if you can create duplicate entry I don't think it would ever be actually assigned to anything. That could cause a bug for any mod that did that, but shouldn't be a concern for you.

well a mod could define a enum as having material.air for flying and then another enum might say flying and go through material of space or something so there is no set definition. I am thinking of enforcing enums to only be one name and put it on the actual modders to use their modid and replace all ":" with "_" for the best way of compatability. I think I am going with your idea since the alternative is a heavy process that would even confuse the users and it would be json hard for users to configure for something that I setup to be really simple.