ItemMapBase -> ItemComplex

[kashike]

While this class is only extended by map classes in vanilla, it isn't directly related to maps at all. Instead, it's an item that can send a packet to the client.

net/minecraft/item/ItemMapBase -> net/minecraft/item/ItemComplex

[Gegy]

Consequently Item#isMap should be changed too. Though maybe ItemSynced/ItemSyncable or something similar would be more descriptive?

[pau101]

My proposal:

• net.minecraft.item.ItemMapBase -> net.minecraft.item.ItemSyncedTickable
• func_77643_m_: isMap -> isAssignableToSyncedTickable
• func_150911_c: createMapDataPacket -> pollPacketTick

This type represents an item whose stacks share a relationship with an auxiliary state that has a presentation on the client. The work function of this type, createMapDataPacket, is one expected to be state-full, warranting application of "tick". This is evident by its nullability supporting the return of a packet only if there is need, as well as the map item implementation internal MapData.MapInfo#getPacket exhibiting observer pattern and periodic tick behavior.

The verbosity of isAssignableToSyncedTickable is motivated by exciplicity for the returnal of true indicating that this item can be safety cast to ItemSyncedTickable.

[williewillus]

not sure why isAssignableToSyncedTickable has to be that long, why not just isSyncedTickable?

[pau101]

@williewillus I addressed that concern in the last sentence of my last comment, but to further explain:

A comparison could be made to Gson's JsonElement design where there are a set of isX for each type X in the hierarchy. However this is a closed type hierarchy, while the Item hierarchy is open. The argument could be made that javadoc explaining intended usage on this function would justify a simpler name, but given the general lack of meaningful javadoc provided by our mappings, developers are not accustomed to consulting them. Furthermore, you could argue that this naming is too verbose because the developer is to blame for not making the effort to adequately familiarize themselves with the code being consumed, however given the ease that this function could be misused, putting greater priority to having adequate javadoc and a function name which does not sacrifice clarity is especially helpful without minimal cost.

In the Minecraft codebase this function has a single call site, and the two declarations. First declaration in Item and second, the override in ItemMapBase. A mod does not have need to declare this function themselves as that would be redundant or breach of contract. A mod needing to call this function would be rare, but when needed there would again, only be single call site needed. The seldom usage of this function in code makes a name on the long side justifiable for purpose of exciplicity.

[williewillus]

my point is that the extra word doesn't really add any additional meaning beyond what was already tere

[pau101]

Yes, isSyncedTickable can imply the item is an ItemSyncedTickable, but it can also read without any recognition of SyncedTickable being a type. The fast majority of isX named functions have X refer to an abstract state or a property of the declaring object. Item functions in this form are Item#isDamageable, Item#isRepairable, and ItemFood#isWolfsFavoriteMeat. The functions isDamageable and isRepairable are not in reference to being assignable to a type and have no dependency on additional state on the object, thus allowing them to return freely, yet isAssignableToSyncedTickable refers to being a type, which is must be, to adhere to contract.