Why Boiler is better than Robotlegs. Pt. 2

I’m starting out with the “not terribly awesome” and perhaps even “that’s crap!” stuff. That is, you might think I’m losing my mind at this point. Remember these are things that I love about Boiler. You might not.

I promise you, though, that the final two articles in this series will be epic. I’ll show you how to extend Steam using ‘commands’ as an example. I’ll also show you how to integrate some syntactic sugar without making the framework brittle.

Sugar be damned.

It’s sugar that I want to discus in this post.

Sugar is usually not the same concern as the base class.

Mediator#addViewListener makes me think that Mediator is-a view listener.

Mediator#addContextListener makes me think that Mediator has-a context bus AND is-a contextListener.

In Steam, neither is true. Mediator is-a class that expects to be told when a view of a specific type has been added to the stage. That’s all it is, period.

Without sugar, there is no Mediator Interface, only duck typing as I explained in the previous article.

It’s all about SRP

Sugar can hide the obvious from tools.

This ones pretty fluffy, purely a matter of taste.

Again with the Mediator sugar from Robotlegs, I would usually start typing:

addContextListener(MyEvent.EVENT_NAME,eventNameHandler);

IntelliJ would highlight the ‘eventNameHandler’ so I could select ‘create method’. Which is great. I can automatically stub out:

public function eventNameHandler():void {
}

That’s not bad… Except if I had used:

myContextBus.addEventListener(MyEvent.EVENT_NAME,eventNameHandler);

IntelliJ would offer to stub out:

public function eventNameHandler(event:MyEvent):void {
} 

Boiler want’s us to avoid hiding language conventions. Kthx?