Closed jaredcwhite closed 2 years ago
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.
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.
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.
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.
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.
IO::Event
could work, but it's not specific toIO
- 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 structureFiber::Scheduler
, Fiber::Loop
, and Fiber::Event
all workScheduler would be great if you can acquire the gem name—same problem in theory, but a lot less likely.
After much consideration, I'm renaming this gem to io-event
and it will use the namespace IO::Event
.
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 ofString
orFile
or whatever), butEvent
seems generic/common enough that I was surprised to run into this issue suddenly. Any thoughts on making this a little more unique likeEventLoop
or something?