An event bus framework for event driven programming | Hacker News Reader

An event bus framework for event driven programming

github.com

36 pointszer0gravity16 comments

    logger.info("...");

versus:

    EventHandle eh = EBus.getHandle(
        eventBuilder.executing().name("some operation").build());
    if (eh.isAllowed()) {
        eh.addParam("p1","v1").addParam("p2","v2").post();
    }

That's a lot of typing.

It needs a more compact API.

With event framework,we should use little helper function to wrap each event type,at least that's what I have seen.Windows event tracing(ETW) comes to mind,one of the complex api written[1].I always thought that every application should make use of ETW infrastrucutre. Compared to perf_events or may be lttng in linux(I am not sure how difficult to integrate to perf_events).Currently there are good and easy framework for ETW in .net [2]. But once you integrate your app,your app suddenly gains performance tuning,debugging capability easily. I think this should hold true for any event framework!!

[1]https://mollyrocket.com/casey/stream_0029.html [2]https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing...

Yes, that's pretty full of boilerplate, even for Java, which is notoriously boilerplate.

There are more established event buses in Android with simpler syntax, like greenrobot's: EventBus.getInstance().post(new LogEvent("v1", "v2"));

Seen here: http://greenrobot.org/eventbus/documentation/how-to-get-star...

You can have multiple event buses and other customization there as needed, but you have sensible defaults to keep code small most of the time too.

Square also has one called Otto. If you want a lot of syntax and Java rather than Android, you might as well go full streaming with the RxJava library.

I think Otto is a fork, and simply an enhanced implementation of Guava's built-in EventBus

meanwhile Otto has become deprecated and the authors suggest going with RxAndroid

Well, to be really fair compare it with :

  if(logger.isDebugEnabled()){
        logger.debug("...");
  }

And yeah, it requires a bit more typting if you want to enforce a certain event format and want to add more parameters. But you only do that once, and I'd say you gain much more for your effort.

Fyi, intended usage with most Java loggers is to just call

    logger.debug("...");

and ignore the conditional. If `!logger.isDebugEnabled` then the logger will ignore the message, so it avoids boilerplate.

You want to wrap it in an if in order to avoid doing extra work ( like string concatenation or whatever ) and save some computation. It's to improve performance when logging is not enabled.

No good if you're computing the message somehow. e.g.

    logger.debug(generateSomethingLarge());

Generally you would log with placeholders, like

    logger.debug("My logger message has placeholders {}, {}, {}", some, objects, toLog);

which avoids the issue.

Event Bus often get abused, I made this framework for Android so that the framework can scale as you have more and more features and developers working on it: https://github.com/edisonw/PennStation

Ill see your event thingy and raise you mine - https://github.com/kashifrazzaqui/again/blob/master/again/ev...

I vastly prefer typed events. All the really important string values scream "you sure aren't testing all of that" to me.

Dupe: https://news.ycombinator.com/item?id=12159452

But you knew that, because it was you who submitted it.

I think that the site auto reposts in some cases when the post gains no traction

Sometimes, but not in less than an hour.

Reply on news.ycombinator.com