`Event` is too general, collides with model in codebase

[jaredcwhite]

I'm trying out the async gem in a codebase and v1 worked great, then I decided to try the latest main branch to see if it would perform any better under Ruby 3, and I ran into an issue where an Event model class I already have in my codebase collided with this gem's module. I realize that's always a danger of some kind (like obviously I can't have a model with a class name of String or File or whatever), but Event seems generic/common enough that I was surprised to run into this issue suddenly. Any thoughts on making this a little more unique like EventLoop or something?

[ioquatix]

This is an unfortunate problem of how Ruby works, and I'm assuming a Rails app that puts all it's constants at the top level. My advice is to move all your models into a namespace specific to your application. No matter what we call this gem, the same problem can happen if you don't use an appropriate namespace for your own code. That being said, I'm not adverse to renaming it if we found something better.

[jaredcwhite]

Yeah, I get what you're saying. It's a tricky balance. I mean, what if someone's gem was named User? Role? Message? etc. could run into weird conflicts.

In lieu of an update, I can change my Event model to something else. It's not a Rails app/record so not too hard to change.

[ioquatix]

I really feel your pain, I just don't know what to do. I made the following suggestion to other Ruby core members:

But there wasn't much discussion. It would be nice to have a "user" namespace separate from a "library" namespace.

And in another note, in the db gem I created, I strongly insist on application specific schema modules to contain your model classes.

[timcraft]

The overloaded meaning of the word event is unfortunate. I've seen it used a lot as a model name in Rails applications used for websites with database-driven event pages, as well as calendaring software, booking systems etc. It could also be used more generally to mean "something that happened", such as with event sourcing patterns.

I would agree with the advice to use namespaces, but I think that's also good practice for lower level libraries as much as applications, and as noted Rails doesn't encourage this. Which due to the runtime dependency makes async a non starter for many Rails apps, a lot of which could really benefit from all this awesome fiber concurrency work!

Whilst solving the problem technically, EventLoop::Event feels clunky here, just as MyApplication::CalendarEvent would at the application level. Would either IO::Event or Async::Event be palatable? I think either of those would work well. Specific enough not to clash, but short. Both the IO and Async modules already carry enough meaning to imply that you're dealing with an "event driven programming" kind of event. Corresponding gem names are available for both.

[ioquatix]

Okay, after contemplation, I'm going to try and rename this gem to "scheduler" and introduce a default scheduler concept which many people have asked me about. However, I have to acquire the gem from an existing owner, so that's currently in progress. Once that's done, I'll consider the options again and hopefully we can make some progress.

• Async::Event could be okay but this gem is actually completely divorced from async by design.
• IO::Event could work, but it's not specific to IO - it handles a variety of non-blocking operations.

For further consideration, fiber-event or fiber-scheduler may also work but I'd prefer to keep it simple.

[timcraft]

IO::Event could work, but it's not specific to IO - it handles a variety of non-blocking operations.

IO seemed like an obvious candidate given the duplication of constants in selector.rb and the IO references in select.rb but I'd agree not the best choice if the concepts are more broadly applicable.

I think Fiber would fit well as the module namespace:

• Fiber::Selector, Fiber::Selector::URing etc with the current structure
• Fiber::Scheduler, Fiber::Loop, and Fiber::Event all work

Scheduler would be great if you can acquire the gem name—same problem in theory, but a lot less likely.

[ioquatix]

After much consideration, I'm renaming this gem to io-event and it will use the namespace IO::Event.