sometimes the usage of a callback is very limited, which makes it in-appropriate to be a member function. so at these times I always want to write the event call backs as lambda functions as the usage is limited the codeblock is compact if wrote in lambda
but this callback is generally defined member functions and there are interface limitations inforced on it
I wonder if it is possbile to rewrite the callback in lambda functions ?
pMenuOK->setTarget(this,menu_selector(PlayerLayer::onPlayed));
void PlayerLayer::onPlayed(cocos2d::CCObject *pSender);
For simple CCCallFunc callbacks that take no parameters, you may want to check out
MCBCallLambda.
I don't think it's possible. The way they are called by Cocos2d-x is by using a target pointer to a CCObject in combination with a method pointer. Thus, the target has to be a CCObject. As you said, these are defined for different types of parameters. Cocos2d-x need to be changed to support this.
It is possible for any method that accepts CCCallFunc [1] or its subclasses. Create own subclass of CCCallFunc which keeps std::function and overrides execute method and maybe some other methods (figure out which implementation needed from CCCallFunc sources).
[1] http://www.cocos2d-x.org/embedded/cocos2d-x/dd/d6e/classcocos2d_1_1_c_c_call_func.html
Related
I'm trying to create a service where a user needs to operate over a data and can manipulate it in numerous ways, so I'm not aware of the manipulations at the time of compiling of my program. One way to achieve this is to give the user a function with data as param. Which landed me in the following direction.
Dynamically create a function
Dynamically linking a function after compiling it separately.
I'm open to suggestions. If you have other ways to achieve the end goal.
If you don't like this as an answer I can move to the comment section, but it's rather long that's why I put here in the answer section.
Dynamically Dispatched Method: The only way to have dynamically dispatched methods is through an interface. Methods on a struct or any other concrete type are always resolved statically.
Closure: Go supports anonymous functions, which can form closures. Anonymous functions are useful when you want to define a function inline without having to name it.
Dyncamically call method on Interface:
Please let me know if that helps you to understand the concept in golang.
In object-oriented languages like C++ you don't have to call the base constructor. I don't understand why I need to do it in a psuedo object-oriented language like javascript. My base constructor has virtual elements that need to be setup before I call it. Constructors worked fine in ES5, why ruin them with this restriction. This error is garbage, it should be removed.
In C++ the compiler creates code to call the base constructor for you before your derived class constructor is called. Your C++ derived class definition can specify which base constructor to call and what to pass it (if there is a choice).
That's how the C++ specification is written. See short explanation here.
Javascript ES6 classes do not work the exact same way. You have to insert a place in your code where the base constructor is called with super(...) and you can specify or compute the parameters to pass to the base constructor.
In both C++ and Javascript, you can't access your own instance methods or properties before the base constructor has been called.
FYI, Java is even more restrictive than Javascript. You must put a call to super() or this() as the first statement of your constructor. Javascript at least lets you put logic that doesn't use this before calling the constructor.
In your Javascript, you can't stop this error without rewriting your code to work a different way. It's not an error you can disable.
There are valid OOP reasons (whether you agree with them or not) to not allow references to an object until all base classes have been fully initialized. Or, you can go back to the pre-ES6 way of initializing objects where there are no controls on how you do things and you can do whatever you want.
If you show us your code and explain what you're trying to do, we can likely suggest a different design that solves your problem and does not have this issue.
According to the documentation for EventMachine.watch_file the handler argument has to be a Module (or a class inheriting from EventMachine::FileWatch). Why is it designed this way? For me a block (or Proc) argument would be more natural and flexible (since it allows to use local variables via closure)...
The docs are not super clear, but you can also supply a sub-class of FileWatch. That would let you use locals more easily.
It takes either a module with the needed methods, or a class with the needed methods AND it must be a sub-class of the desired class.
Take a look at the code, specifically, the klass_from_handler method.
Just something that has been playing on my mind recently. A java example of what I mean by an inbuilt method: System.out.println("hi");. How does this method actually make 'hi' appear on screen? I can imagine a long series of methods inside methods inside methods, but how would the 'base' method do what it is supposed to?
this is a good example for println. http://luckytoilet.wordpress.com/2010/05/21/how-system-out-println-really-works/
Essentially, the call gets processed through the call stack, until it reaches native code, then you're into OS specific code, i.e. the windows API.
As per my understanding, unlike functions, event handler receives the event object as parameter.
Is there any other difference between those two words or both are similar?
Can anyone elaborate both the terms?
It really depends on the specific language and API you are using. In C for instance, event-handlers are usually implemented as functions. in C++ they can also be callable objects. Other languages may offer different options.
It may depend on the language. Event handler is a function which often has a special parameter (in most cases) where the parameter is the event object.
So no, there's really no difference between an event handler and a function. You could easily call an event handler just as you would call a function, except you would have to pass some event object to the event handler function, which is not always the case.
Basically you would never call an event handler as you would call a function, you would have something invoke the event when something is triggered, that may be the only difference.
I hope this post is helpful.
Well, event handlers are specific to the framework you use. Java's GUI model is based on even handlers, typically you pass an anonymous inner class that implements the expected interface (like KeyListener) to the addKeyListener (or similar) method.
In C, you typically use function pointers to the same effect. A button struct would hold a function pointer to a callback, and this function could be passed an event struct.
C++ allows you to use the function-pointer idea, or you can define an object that runs some method when you try to 'call' it - some_obj() on a suitably-defined object would call some function of your choice. You could even make it take arguments. Python is like this as well.
If a callback takes a parameter that specifies the event, it's typically called an event handler. But they can be used pretty much interchangeably.