hxdefold
hxdefold copied to clipboard
implement higher-level API on abstract
it should be possible with Haxe to implement a very nice OO-ish API on top of the basic defold api with zero run-time cost using abstracts. look into that.
another idea would be to provide macro-powered sugar for handling and sending messages (see https://forum.defold.com/t/haxe-defold/44368/8)
that begs for property sugar as well, ok now I want to design something :)
Would this API be ok?
import defold.support.CallbackDispatch;
override function on_message<T>(self:Props, message_id:Message<T>, message:T, sender:Url)
{
// Macro function to generate callback calls.
CallbackDispatch.dispatchMessage(message_id, message, sender);
}
Then the callbacks could look like this:
typedef MessageOne = {
var param1: Int;
var param2: Vector3;
}
typefdef MessageTwo = { ... }
@:message function onMessageOne(self:Props, sender:Url, msg:MessageOne) { }
@:message function onMessage2(self:Props, sender:Url, msg:MessageTwo) { }
The message type here is deducted from the third parameter.
Another alternative would be to do it like this.
@:message(msg:MessageOne) function onMessageOne(self:Props, sender:Url, param1:Int, param2:Vector3) { }
A bit prettier, but would cause compilation errors when the message typedef is updated, all callback methods using said message would need to be updated manually.
Then I'm also thinking we could have generated public static methods for posting messages.
public static inline function postMessageOne(url: Url, param1: Int, param2: Vector3) {
// The message id will of course be pre-hashed somewhere.
Msg.pos(url, hash("_TypeName_MessageOne_",
{
param1: param1,
param2: param2
})
}
Or is it better to not have statics at all, and go straight for an abstract OOP implementation? I have sort of started doing something similar here.
Ditto all of the above for on_input as well.