TickedSystems handled by addTickedSystem

[vrobel]

I think it would be cool to have a base TickedSystem with protected update method. There would be a method in Ember class: addTickedSystem(MyTickedSystem, TickSignal). There's no problem with that if Signal has no params. But with params it can cause some problems. Anyway - would be nice to have such a feature

[vrobel]

I realized that it generates code that relies on Signals, but Robotlegs team is working on abstracting Events and Signals into Triggers which can be helpful in the future

[vrobel]

I think it would be better to do that part by using generators of any kind using e.g. templates.

[alecmce]

Hmm, I'm cautious about this. Although almost all systems will require some sort of tick, if the system itself creates and manages the TickSignal then the user has no control over the order of the signals. I am more open to the thought of extending Ember.function addSystem(systemClass:Class):Object to Ember.addSytem(systemClass:Class, ... injections):Object where injections can be automatically injected into the system on construction. Perhaps that would serve a similar purpose but not push users into a particular pattern.

I've changed the name of 'Ember' to 'Game', because Ember uses the name 'Game'. I didn't like it to start with but I've agreed that I should try to conform to Tom's original nomenclature in this aspect at least.

Oh, Signals are already part of the core functionality - I use them to manage nodes internally, so no problems there!

[vrobel]

I didn't mean creating new signal inside a system, but providing class and get a mapped instance from the injector.

[alecmce]

If a signal's mapped in the injector, then it will be injected into the system anyway, since the system is constructed via the injector. Either use constructor injection or [Inject] to reference it just as you would in a Mediator!

[vrobel]

That's clear for me. I was just wondering how to remove manual injection and adding listener :)

[alecmce]

Yeah, I completely understand what you're aiming for :)

I think we see the library slightly differently - you're wondering what more it could do for you, while I'm trying to make sure that it does only a clearly defined set of things, but does that really really well! I want SwiftSuspenders to do what it does really well, and not wrap too much of SwiftSuspenders functionality into xEmber.

Still, I really appreciate the thoughts - please keep making suggestions and comments. Or, if you feel strongly about something, branch and implement - you can always run a parallel implementation and keep merging in the my master!

[vrobel]

Will do. As I wrote in the other issue - I have to shift my thinking a bit.

[alecmce]

Closing for now, I don't think this is an actionable issue. Thanks for the thoughts though!