Within the context of re-frame’s interceptor, coeffects / effects concepts I’m wondering what the recommended architectural approach is for events that are driven by a timer / cyclical event.
In one of the github examples a clock is made by defining a top level JavaScript interval at the namespace level (essentially a global).
In react this is the type of thing you would organize using component lifecycle hooks. What is a recommended way of organizing these types of event drivers (timers and request animation frame game loops)?
Related
I'm working on applying RL techniques in a real-time task and I've created a custom environment following OpenAI Gym interfaces. I'm trying to utilize a method of dynamically setting the time interval of interactions (the same as setting the time of calling step function) but I have no idea of how to implement this with Ray RLlib.
I've checked the rollout worker and custom evaluation in RLlib but it seems the further modification to RLlib is needed. So is there a simple way to do this? Or is there another RL framework which could be helpful? Thank you very much!
I am a bit confused about which invalidate method to use and when to use it. I need to change x and y of a component and in that case one should call a invalidation method for optimization, but i don't know which one and when exactly
target.addElement(node);
node.x = 100 + target.horizontalScrollPosition;
node.y = 100 + target.verticalScrollPosition;
node and target are both Groups
It depends on the component and perhaps you don't have to call any at all. From the given piece of code i'd say it's invalidateSize(). But containers usually make a good job of measuring their dimensions property. invalidateDisplayListmight be a good call, if you need to change the way the component is displayed.
So, generally speaking, it depends on the component (super type etc) you are implementing.
Edit:
As both instances are groups, you shouldn't call any invalidation methods at all. You would only call the methods when implementing a custom component with additional properties. In the case of Groups, anything has been done for you in advance. The component live cycle is implemented and the various layouts provide a comfortable level of indirection.
When you extend Group (or any other component) then you should be familiar with the component live cycle.
Rule of thumbs:
ignore the invalidation calls in pure MXML as it is done by the MXML compiler and the components themselves.
use the invalidation calls in overridden setters, which mutate the state of the component (even in MXML). This usually leads to a clean yet simple design of components if the setters are used everywhere - even inside the components private methods.
use validateSize, validateNow etc carefully, as these are simple synchronous shortcuts avoiding the component live cycle.
The invalidation live cycles is based on the flash players elastic race track, which which divides rendering and processing of the data in different aspects processing the code.
Further readings regarding the idea behind the invalidation calls:
Updated elastic racetrack[1] and The Elastic racetrack[2]
[1]: http://www.craftymind.com/updated-elastic-racetrack-for-flash-9-and-avm2/
[2]: http://tedpatrick.com/2005/07/19/flash-player-mental-model-the-elastic-racetrack/
I am wondering what is better practice - Should classes listen for a global event or should a manager listen for the event and then call public methods on those classes?
for example:
import App
public class DualLanguageText
{
public function DualLanguageText():void
{
App.Model.addEventListener(AppEvent.CHANGE_LANGUAGE, onChangeLanguage)
}
}
...or
import App
public class ViewManager
{
public function viewManager():void
{
//Create Text Components
App.Model.addEventListener(AppEvent.CHANGE_LANGUAGE, onChangeLanguage)
}
private function onChangeLanguage(e:AppEvent):void
{
for each (var dtext:DualLanguageText in _textComponents)
{
dText.changeLanguage(e.id);
}
}
}
The correct answer is that neither of these is optimal architecture, but, of the two, the second is the better option.
You should never expose anything globally. Objects should only have references to the objects that they are given references to http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons. But if you're going to do this, you should limit the number of objects making an end-run around their published API's.
Might I suggest that you do something else? Modern Frameworks, such as RobotLegs, handle this by providing a reference to a single IEventDispatcher that serves as a communication channel, or event bus. One concept that RobotLegs has that is really nice is the concept of a Mediator, a component that simply listens to the event bus and propagates changes to a View component, as well as listening to a View component and generating Events to be published to the bus.
I mentioned Robotlegs because it works just as well in Flash as Flex. You can also "roll your own" by listening on the stage for objects to be added and then creating controllers for them or injecting them with data (similar to this http://www.developria.com/2010/04/combining-the-timeline-with-oo.html). However, Robotlegs is relatively mature at this point, and they've worked out kinks you probably haven't thought of yet. You can get it at http://www.robotlegs.org .
I, personally, would worry less about the performance hit of events and more about the maintenance costs of creating a project where everything is tightly coupled and it's difficult to determine where a bug was introduced (because all parts of the application can touch your model).
The answer is: It depends. :)
In general, I would consider it to be good practice to have a main controller dispatch all application-wide events and add listeners from all the objects that need to be notified.
But event handling is a rather slow mechanism, and there may be some occasions, when you want a manager class to distribute the notifications in imperative style. One (rather crude) example would be, when you have a lot of enemies in a game, that you need to update on Event.ENTER_FRAME - adding an onEnterFrame listener from every single object would significantly slow down your application compared to calling an update() method on each enemy instance from an EnemyManager class. (Of course, you can catch ENTER_FRAME on every DisplayObject - like I said, it's a crude example, but it illustrates my point.)
In all the ActionScript examples I come across, people write custom events with the types defined inside the custom event's class definition. But, in my experience, it makes more sense for the object dispatching an event to own its own definition of that event (which, in ActionScript 3, is a String).
[EDIT: After writing this question, I've found there to be cases for both positions -- in some situations, event types should be stored on the event object, and, in others, they should be stored on the object dispatching the event.]
Please tell me what your take is on this and where you find yourself storing event types.
Over the last few years, I have actually been using a combination of these, mainly in the context of PureMVC. Flash instances (view components) catch Flash events, and then dispatch an Event, where the type is a static string defined in that class. The mediator catches the view components events, and then sends notifications where the notes are defined in the central application facade class. I also try as much as possible to not subclass Event, and to minimize passing data around in note bodies.
I feel that this allows the most flexibility to rework both interfaces and application logic, and also provides more reuse of proxies and mediators/components between applications.
If event the dispatcher has code pertaining to the definition of the event than the dispatcher arguably is in-cohesive. I would tend more towards having the event dispatcher implement a stable interface thus protecting it from variations in the events. This will also reduce coupling to the dispatcher and allow for greater flexibility in handling events.
My professor gave my class an assignment today based on object oriented programming in Pygame. Basically he has said that the game that we are to create will be void of a main game loop. While I believe that it is possible to do this (and this question has stated that it is possible) I don't believe that this is required for adherence to the Object Oriented paradigm.
In a diagram that the professor gave, he showed the game initializing and as the objects were instantiated the control flow of the program would be distributed among the objects.
Basically I believe it would be possible to implement a game this way, but it would not be an ideal way nor is it required for Object Oriented adherence. Any thoughts?
EDIT: We are creating an asteroids clone, which I believe further complicates things due to the fact that it is a real time action game.
Turn based games or anything event driven would be the route to go. In other words, take desktop GUI apps. They'll just tick (wait) over until an event is fired. The same could be done for a simple game. Take Checkers for example. Looping each game cycle would be overkill. 90% of the time the game will be static. Using some form of events (the observer design pattern would be nice here) would provide a much better solution. You're using Pygame, so there may be support for this built in, through due to my limited use I cannot comment fully. Either way, the general principles are the same.
All in all it's a pretty rubbish assignment if you ask me. If it's to teach you event driven programming, a simple GUI application would be better. Even the simplest of games us a basic game loop, which can adhere to OO principles.
Hmm. In the general case, I think this idea is probably hokum. SDL (upon which PyGame is implemented), provides information to the program via an event queue, and consuming that queue requires some sort of repeatedly checking the queue for events, processing them, and waiting until the next event arrives.
There are some particular exceptions to this, though. You can poll the mouse and keyboard for their state without accessing the event queue. The problem with that is it still requires something like a loop, so that it happens over and over again until the game exits.
You could use pygame.time to wait on a timer instead of waiting on the event queue, and then pass control to the game objects which poll the mouse and keyboard as per above, but you are still 'looping', but bound by a timer instead of the event queue.
Instead of focusing on eliminating a main loop, how about instead think about using it in an object oriented way.
For instance, you could require a 'root' object, which actually has its own event loop, but instead of performing any action based on the incoming events, it calls a handler on several child objects. For instance when the root object recieves a pygame.event.MOUSEBUTTONDOWN event, it could search through it's children for a 'rect' attribute and determine if the event.pos attribute is inside that rect. if it is it can call a hypothetical onClick method on that child object.
I think it might qualify as event driven programming? Which can still be object oriented. You see this in Flash a lot.
There's a difference between a main loop in a main class. You can still have a game class initialize all of your objects, and then rely on inputs to move the game onward.
Kinda hard to say exactly without knowing the exact parameters of your assignment, the devil is in the details.
You might look at how python utilizes signals. A decent example I found is at: http://docs.python.org/library/signal.html