Fix automatic IPeripheral detection

This is a Java-side suggestion to make life easier on developers.

Currently, every developer has to register an IPeripheralProvider in order to make their mod work. This seems unnecessary to me, and in most cases, can be avoided by the following snippet of code inserted somewhere after the API is initialized in ComputerCraft:

ComputerCraftAPI.registerPeripheralProvider(new IPeripheralProvider() {
    @Override
    public IPeripheral getPeripheral(World world, int x, int y, int z, int side) {
        TileEntity tile = world.getTileEntity(x, y, z);
        if (tile instanceof IPeripheral) {
            IPeripheral peripheral = (IPeripheral) tile;
            return peripheral.useDefaultDetection() ? peripheral : null;
        }
        return null;
    }
});

Then, to allow custom implementation if the author so wishes, just add

boolean IPeripheral.useDefaultDetection()

Please let me know if I'm just being dumb, but I have had no luck (and others haven't as well) with getting IPeripherals to be detected by ComputerCraft without an IPeripheralProvider.

I remember talking about that with dan200, but that thought could have been changed over time.

I said something about it in the following topic: http://www.computercraft.info/forums2/index.php?/topic/18345-please-help-custom-peripherals-are-not-recognized
I can't clearly remember the contents of the conversation I have had, but I know for sure that it is recent at the date of given topic

It is a pretty simple class, that you only need one of… it's pretty create-register-forget, while yes auto IPeripheral wrapping would be handy, and if it were an IPeripheral that states it wishes to be wrapped by a provider would work in most cases, it would severely break setups used by myself and other developers where we are making attempts at making development easier; especially since the block would need to be an IPeripheral, in order to state it wishes to be handled by a provider (a rather pointless task, what would the provider do different in this case?)
For example with my Peripheral-Framework —which has the aim of neatening up development— a peripheral doesn't actually implement the IPeripheral interface, but instead uses annotations to mark key aspects of the peripheral; this is its peripheral provider which wraps those annotated classes into IPeripherals. Lyqyd's solution is similar, but uses custom interfaces and classes to achieve the same result, also making use of a peripheral provider which does wrapping. But the biggest mod it will impact, OpenPeripherals, which the community wouldn't like at all!

theoriginalbit, on 20 December 2014 - 10:08 PM said:

Snip

I surely agree with your point, as I have made such a similair framework myself.
In the OP it is suggested that it stays optional, hence it is overrideable.

It also decreases the amount of classes which are stored in CC (CC uses a List to store the providers and iterates through it), because most of them will be similair to the class the OP posted.

Engineer, on 21 December 2014 - 02:22 AM said:

In the OP it is suggested that it stays optional, hence it is overrideable.

overridable by a method you must define on the IPeripheral, thus making it a useless method, especially in the case where the TE doesn't implement an IPeripheral.

When the TE doesn't implement IPeripheral, you have to write your own provider.

lets say the method gets removed, it still can't hurt at all.

Engineer, on 21 December 2014 - 02:40 AM said:

-snip-

okay, yes, when it doesn't have an IPeripheral you'd make a provider. However, when do you see the need to have the OP suggested method useDefaultDetection on an IPeripheral return false so it is loaded by a provider…?

Actually, I cannot think of one example when you'd use that method. But I reckon someone is going to need to be able to disable that automatic detection, so it should be possible.

Edit:
After thinking about it, one can check conditions in that method if the peripheral is valid to use. Imagine it really needs another block next to it to function properly or it must be peripheral structure of sorts. One would use that method to check for that :P/>

You could still accomplish the same with an IPeripheralProvider and removing the IPeripheral from the block.