19 ms·

Maybe I'm dumb but I've read your comments a few times over and I still haven't quite understand what you were trying to say. "Calling methods via strings wher

by ncann 5y ago

Maybe I'm dumb but I've read your comments a few times over and I still haven't quite understand what you were trying to say. "Calling methods via strings where you control all the source code to your own application " -> what do you mean by this and how is it relevant to this library?

wffurr 5y ago
Instead of posting a string and a payload to the event bus, which a listener picks up and unpacks to call method in the receiver, just call the method. It does introduce a direct dependency where it was indirect before, but is otherwise much simpler and significantly faster than all the string comparisons.
- void_mint 5y ago
  > It does introduce a direct dependency where it was indirect before Which is okay if you've used any amount of DI and testability-focused thinking to set up your code. The event bus pattern works great if you don't know (or want to know) what's going to happen to an event once it's emitted. If the only thing that happens is a different method in your app gets triggered, you should really just trigger that method and skip the event bus altogether.
- ncann 5y ago
  Ah ok I guess my confusion is from the fact that there's no explicit "string" being passed around with this library, but the concept of a payload makes sense.
- hota_mazi 5y ago
  Introducing the direct dependency is exactly what you want to avoid and what event buses provide. With your approach, you are coupling views and model with n*m links, with an event bus, it's just n+m. Much easier to decouple your logic. I do agree with you that I'm not a fan of the loss of static typing that event buses usually introduce.
  - an_opabinia 5y ago
    > Introducing the direct dependency is exactly what you want to avoid Why? It's a GUI application on Android. Everything that listens to this event bus is a direct dependency configured at build time. Every modern optimization, like ahead of time compilation and code stripping, benefits from direct dependencies. This is why I used the word toxic, and not stupid.
  - the_gipsy 5y ago
    Calling by strings is not decoupling. You just fooled the type system. Or yourself, if you want.
- chris_overseas 5y ago
  There is no string comparison here, the subscriptions and posting of events is based on the class of the POJO being sent.
Quekid5 5y ago
I think they might be referring to Stringly Typed Programming.
an_opabinia 5y ago
EventBus uses an annotation processor and reflection to reify a call. A ton of things look like this. Like that's also sort of what a REST API is. It makes a ton of sense for crossing boundaries from owning the code to not owning the code, and back again. But since you own the code, you own 100% of the source in your GUI application, why would you need indirection? There's no reason to hide part A from part B. That's why giant companies who author all their stuff in house use monorepos. I can't believe I'm saying this, but hiding stuff, like trying to mark code as proprietary or "not maintained by my team" (as Amazon would do), is a social construct. This is relevant to the library because many times, people who have the experience of using this library in real Android apps and having a positive experience with it - they are using the library for to do, "my team does this part, and this other team does that part." "This developer is stupid and junior, so must decouple their work." Toxic! Amazon: extremely toxic. If I were a code anthropologist, DI and EventBus would be, "Artifacts of toxicity." When you look at how it's used by other apps, like Signal for Android, with small teams, it just looks stupid, and they work around its warts anyway, and use direct calling anyway, just in a far more roundabout fashion.
- ncann 5y ago
  > But since you own the code, you own 100% of the source in your GUI application, why would you need indirection? So what is your proposed non-indirection way? I'm assuming you meant the traditional listener/observable way of registering event producers and event listeners together, in which case this FAQ explains pretty well their downsides compared to an event bus: https://github.com/google/guava/wiki/EventBusExplained#faq https://github.com/google/guava/wiki/EventBusExplained#faq

by ncann 5y ago

wffurr 5y ago

Instead of posting a string and a payload to the event bus, which a listener picks up and unpacks to call method in the receiver, just call the method. It does introduce a direct dependency where it was indirect before, but is otherwise much simpler and significantly faster than all the string comparisons.

void_mint 5y ago
> It does introduce a direct dependency where it was indirect before Which is okay if you've used any amount of DI and testability-focused thinking to set up your code. The event bus pattern works great if you don't know (or want to know) what's going to happen to an event once it's emitted. If the only thing that happens is a different method in your app gets triggered, you should really just trigger that method and skip the event bus altogether.
ncann 5y ago
Ah ok I guess my confusion is from the fact that there's no explicit "string" being passed around with this library, but the concept of a payload makes sense.
hota_mazi 5y ago
Introducing the direct dependency is exactly what you want to avoid and what event buses provide. With your approach, you are coupling views and model with n*m links, with an event bus, it's just n+m. Much easier to decouple your logic. I do agree with you that I'm not a fan of the loss of static typing that event buses usually introduce.
- an_opabinia 5y ago
  > Introducing the direct dependency is exactly what you want to avoid Why? It's a GUI application on Android. Everything that listens to this event bus is a direct dependency configured at build time. Every modern optimization, like ahead of time compilation and code stripping, benefits from direct dependencies. This is why I used the word toxic, and not stupid.
- the_gipsy 5y ago
  Calling by strings is not decoupling. You just fooled the type system. Or yourself, if you want.
chris_overseas 5y ago
There is no string comparison here, the subscriptions and posting of events is based on the class of the POJO being sent.

Quekid5 5y ago

I think they might be referring to Stringly Typed Programming.

an_opabinia 5y ago

EventBus uses an annotation processor and reflection to reify a call. A ton of things look like this. Like that's also sort of what a REST API is. It makes a ton of sense for crossing boundaries from owning the code to not owning the code, and back again. But since you own the code, you own 100% of the source in your GUI application, why would you need indirection? There's no reason to hide part A from part B. That's why giant companies who author all their stuff in house use monorepos. I can't believe I'm saying this, but hiding stuff, like trying to mark code as proprietary or "not maintained by my team" (as Amazon would do), is a social construct. This is relevant to the library because many times, people who have the experience of using this library in real Android apps and having a positive experience with it - they are using the library for to do, "my team does this part, and this other team does that part." "This developer is stupid and junior, so must decouple their work." Toxic! Amazon: extremely toxic. If I were a code anthropologist, DI and EventBus would be, "Artifacts of toxicity." When you look at how it's used by other apps, like Signal for Android, with small teams, it just looks stupid, and they work around its warts anyway, and use direct calling anyway, just in a far more roundabout fashion.

ncann 5y ago
> But since you own the code, you own 100% of the source in your GUI application, why would you need indirection? So what is your proposed non-indirection way? I'm assuming you meant the traditional listener/observable way of registering event producers and event listeners together, in which case this FAQ explains pretty well their downsides compared to an event bus: https://github.com/google/guava/wiki/EventBusExplained#faq https://github.com/google/guava/wiki/EventBusExplained#faq