When creating 'BasicItem', 'BasicBlock', 'Basic[ToolName]' etc Classes, I have found that they all have some identical constructor sections. I have created a generic util method but I feel absolutely filthy for doing it this sloppy way. However, Generics don't allow you to call methods on the 'actual' type because that would break encapsulation. That was the only other way I saw this working. Is there anything I'm forgetting or missing out on? I just really feel like a heathen for doing it this way

public static <T extends IForgeRegistryEntry.Impl<T>> void initItem(T item, String unlocalisedName, String registryName) {
    if (item instanceof Block) {
        ((Block) item).setUnlocalizedName(NameUtils.formatUnlocalisedName(unlocalisedName));
        ((Block) item).setRegistryName(registryName);
        ((Block) item).setCreativeTab(ExampleMod.EXAMPLE_TAB);
    } else {
        ((Item) item).setUnlocalizedName(NameUtils.formatUnlocalisedName(unlocalisedName));
        ((Item) item).setRegistryName(registryName);
        ((Item) item).setCreativeTab(ExampleMod.EXAMPLE_TAB);
    }
}

 

13 minutes ago, hoodwink_dude said:

When creating 'BasicItem', 'BasicBlock', 'Basic[ToolName]' etc Classes, I have found that they all have some identical constructor sections.

Let me stop you right there. Don't create BasicX. There is already a BasicX, it's called X.(BasicBlock -> Block, etc.) This is an antipattern and should be avoided.

 

14 minutes ago, hoodwink_dude said:

Generics don't allow you to call methods on the 'actual' type because that would break encapsulation. That was the only other way I saw this working. Is there anything I'm forgetting or missing out on?

Use an interface to define your contracts?

8 minutes ago, diesieben07 said:

This. However, you need to be careful, since even though Block#setUnlocalizedName and Item#setUnlocalizedName have the same signature at dev time, they will have separate SRG names in the actual game, so you will not be able to have them implement a common interface. You'll need to write your own methods, still.

This is what I was afraid of.

 

12 minutes ago, V0idWa1k3r said:

Let me stop you right there. Don't create BasicX. There is already a BasicX, it's called X.(BasicBlock -> Block, etc.) This is an antipattern and should be avoided.

I guess I got too stuck into this 1.12.2 tutorial series that I didn't stop to think if it was really needed. It's a good thing this has been caught relatively early. Thanks

25 minutes ago, V0idWa1k3r said:

Let me stop you right there. Don't create BasicX. There is already a BasicX, it's called X.(BasicBlock -> Block, etc.) This is an antipattern and should be avoided.

In the context of the linked tutorial, “basic” can be replaced with “example”