[1.10.2] Is this a bug?

[Starless]

class ItemStackHandler
{
    @Override
    public void setStackInSlot(int slot, ItemStack stack)
    {
        validateSlotIndex(slot);
        if (ItemStack.areItemStacksEqual(this.stacks[slot], stack))//this, wasn't this function supposed to have it's return negated?
            return;
        this.stacks[slot] = stack;
        onContentsChanged(slot);
    }
}

[Draco18s]

if(stacks are the same): return

else: put stack in slot

 

 

Soo...no.

[Starless]

if(stacks are the same): return

else: put stack in slot

 

 

Soo...no.

 

so I have 3 blocks of stone in inventory slot 1, I want to put 3 other blocks of stone in inventory slot 1. I can't? I don't even think this method should be used at all. it compares stack sizes, which makes no sense in the context.

[Ernio]

While I agree - "set" (setStackInSlot) means that you are setting instance and should be literally "inv[slot] = stack", you can't argue with the logic behind it - If stacks are already equal = do nothing, else = set it to one you want.

 

Still, this is not bug, rather design choice.

 

Also - there most certainly won't be negation like you proposed.

 

P.S: You can always override

[Starless]

While I agree - "set" (setStackInSlot) means that you are setting instance and should be literally "inv[slot] = stack", you can't argue with the logic behind it - If stacks are already equal = do nothing, else = set it to one you want.

 

Still, this is not bug, rather design choice.

 

Also - there most certainly won't be negation like you proposed.

 

P.S: You can always override

 

You are right, I guess. I don't know the call hierarchy of this method so whoever are its caller must know what they're doing.

[coolAlias]

Anyone can call that method at anytime, and it does exactly what it says it does: it sets the slot contents to the stack provided. If you have 3 stone and want to add 3, you create a stack of 6 stone and use that as the argument to this method. That's how this method has always worked.

 

As for the stack comparison and return, I would guess that is to avoid needlessly calling #onContentsChanged, a presumably potentially expensive operation - probably ends up forcing a write to disk down the line somewhere.