One thing I was working on today was on a trade system for Relic. A criteria I valued was that I didn't want a central class for deciding what the trading does. So I was brain-storming, and I came across an idea from my Java course... Interfaces does not force how a function works... Instead, it mainly states that the object inherits a particular function subset.
So I was thinking of how I can imply this. My main goal is to have it so when I drag an item over a tradable object, it shows a trade-icon... So... I decided that what I needed was an interface for all items that can trade.
In Graal, I know that classes contain codes inside them... But of particular interest, classes are in the joinedclasses variable ( which happens to be set both clientside and serverside ). So what I did was made the object join an interface. If the object complies to the interface, it stays in the class list... If it doesn't, it just removes itself.
This way, in clientside... I know ALL objects that inherit the interface-tradable all contain the necessary code to handle such items.
I hope this concept helps. ( This doesn't make a distinction between private/public functions, nor do they imply that the functions do what they should )
PHP Code:
function onCreated()
{
if ( !isTradable() )
leave( "interface-tradable" );
}
function isTradable()
{
// Test to see if the functions in the object correspond to those of the interface
temp.functions = getFunctions();
temp.tradeFunctions = {"addItem", "getItems" };
for ( temp.func: temp.tradeFunctions )
{
if ( !(temp.func in temp.functions) )
{ // Object doesn't contain a function in interface criteria
return false;
}
}
return true;
}
Please note that the onCreated trigger is executed in the NEXT tick. That is, the object will still be in the class until 0.05 seconds later. If you require an immediate answer, either sleep(0.05) before testing, OR use this:
PHP Code:
if ( isinclass("interface-tradable") && isTradable() )
stuff;
Also note that if the functions were inherited by other classes, and those classes were removed at a later date, that the class itself may still be in the interface class but doesn't fill the interface requirements. Again, if such an issue arises, the previous counter-measure will still work as expected.