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.
Related
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.
Is lib a special keyword for Frogatto Formula Language (FFL)? That seems to be the way of invoking class methods. For example:
where frog = lib.citadel.create_creature('Giant Frog')
Also, I am interested to know where can I find a list of all the available lib.**** library objects and how to list of all their available functions.
I wouldn't call it a keyword as such, more a symbol that appears in the standard namespace. As such it is functionally fairly close to a keyword.
When you create a class by adding a file e.g. data/classes/blah.cfg then a singleton instance of this class will be available using lib.blah. This is a convenient way of effectively creating your own namespace of functions -- create a class, add functions to it, then your functions can be accessed using lib.classname.functionname()
Let's say in Java, I have class CryptoFormat, which has a static method named getLegacyFormat(). When I want to use the method, I just need to call CryptoFormat.getLegacyFormat(). This is clear because I know where the method comes from.
In Go, there is no static method. I don't really want to just make a file called crypto_format.go and define the method there. The reason is that whenever I need the method, I just call GetLegacyFormat(), which doesn't contain the context where the method comes from.
I could think of two ways to solve the problem:
Make a separate package named cryptoformat, and define the method as a global function in the package. This way, I need to make a new package for just few methods. Also, whenever I need static methods like this, I have to define new packages.
Define a struct named cryptoFormat containing method GetLegacyFormat(). Also, define a global public variable named CryptoFormat, which points to an instance of struct cryptoFormat. This way, I can call CryptoFormat.GetLegacyFormat() when I need the method.
I am not sure which one is better, or whether there is better way.
I would say option 1 you mention is the more idiomatic way to define such functions, if they don't need any state that would warrant to tie them to an underlying struct.
If there is some state you'd like to have as context for the function, then option 2 would be the way to go.
Note that in Go, functions are "first class citizens", so you don't have Java's constraints of needing to define a class for static methods.
And yes, if you want a separate namespace you'd need to define separate packages (just as in Java you'd need to define separate classes and/or packages).
If you want your implementation to be idiomatic, I'd suggest you take a look at Go's standard libraries (pick a few packages and explore how they implement their functions) to get a better feeling of the usual ways to structure this.
whenever I need the method, I just call GetLegacyFormat(), which doesn't contain the context where the method comes from.
So add context to the function name.
GetLegacyCryptoFormat()
I am trying to get my head wrapped around "key-value coding".
Apple's docs say:
This document describes the NSKeyValueCoding informal protocol, which
defines a mechanism allowing applications to access the properties of
an object indirectly by name (or key), rather than directly through
invocation of an accessor method or as instance variables.
Few thing are confusing me
Accessor methods are automatically generated for properties, and provide several benefits like memory management, custom validations, etc. When we access a property without the accessor methods as the Apple doc says, does that mean we are losing the benefits of accessor methods?
If KVC is so good and it reduces code, why should I use accessor methods, or why are accessor methods still around?
I have never seen in any tutorial or books, or code on GitHub using KVC. Why is it not adopted that widely?
No, it just means that you aren't explicitly calling the accessor in your code. The accessor is called for you by the KVC implementation.
KVC doesn't necessarily reduce code, rather it allows a different way of interacting. It allows more runtime flexibility and it can allow the use of key paths. You shouldn't look at it as a full replacement, just as an alternative which is appropriate in some cases.
It is used widely, you need to look for calls to valueForKey:, setValue:forKey: (the methods of the protocol - there are many more than just these couple).
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