Some magic needed to prevent overriding generic peripherals with dynamic peripherals

[SirEndii]

Heyo
I currently have the issues that any GenericPeripheral is overwritten by our integration system.
As example, the basin from the create mod. ⇒ IntelligenceModding/AdvancedPeripherals#365
But we're unable to change this behavior without making too many changes.
We currently use IDynamicPeripheral for our integration peripherals to support our plugin system.

Is there any magic in cc that we can use to prevent this?

[SquidDev]

Is there any magic in cc that we can use to prevent this?

Nooooo, not really.

[SirEndii]

This is an interesting approach
but I doubt that this will be reality in the near future

[SquidDev]

The design of the generic peripheral system was very much me looking at how complex Plethora's implementation was and going "hell no, let's make this simple". Now, I don't think I was successful at that - making things simple has never been my forte - but also I feel a UPW-style system takes things further towards Plethora's "hell no", not further away.

There's a lot of deficiencies in the generic peripheral system (I've bumped into a few recently), so I definitely appreciate any and all ideas on how to change/fix things. I sure don't trust myself to get it right :D.

[SquidDev]

This I guess also goes for the whole @LuaFunction system in general. One of its big issues is that everything is tied to the Java object hierarchy, which makes building anything which doesn't fit that model pretty awkward _{^{(something something composition over inheritance)}}. We've actually got a hack around that, it's just never made its way into the public API :D.

[SirEdvin]

I can probably suggest just move generic peripheral into public API part, with some ajustments (like adding extra itemHandler extractors, etc) and then just provide example of how another peripherals can just embed this peripheral into new one with IDynamicPeripheral magic

[SirEdvin]

Even providing extra class, that will handle this dynamic magic internally