Should TaskbarProgress be a module?

[thomthom]

Does it make sense for it to be a class?

Maybe if we add more utility methods that need to keep track of data per instance?

[DanRathbun]

First of all only Ruby Core classes should be defined inTOPLEVEL_BINDING(ie, that particular instance ofObjectcalled <main>.) It should be wrapped in a namespace module somewhere.

---

Secondly, it may be more powerful as a mixin module.
ie, CommunityLibrary::Mixin::TaskbarProgress
Then multiple coders can create a class in there own namespaces and modify them, as well as creating a basic core UI class, if you wish, ex:

require "su_taskbar_progress"
module UI
  module Windows
    class TaskbarProgress
      include CommunityLibrary::Mixin::TaskbarProgress
      # overrides and extra methods ?
    end # class
  end # module Windows
end # module UI

Other coders do the same only within their own namespace(s).

They could actually have slightly different classes for different plugins.

---

Third. Instance data. Attributes can also be setup in a mixin module to initialize when mixed into a class. But starting with a class means you can't make it a double duty library module. (Ie, one that can be called directly via a module function for the most basic features, or mixed into other modules and classes.)