I cannot control what other people say, nor when. This is a public forum.
Ruby is multi-paradigm. There is more than one way to accomplish tasks, but not all are equal in benefits or side-effects.
Doing things wrong helps you learn what not to do. And sometimes learning is “painful”.
But the rewards are great, so enjoy that “pain” while it lasts.
Good news! You are mistaken. The SketchUp native tool IDs are constants and published in the API documentation. It is the Ruby extension tool IDs that can very with each session and order of extension load.
This code above would define a singleton method upon the
Sketchup::EntitiesObserver class itself. That is a very big “no-no”.
@Aerilius is correct you should at the least, use an instance …
@myEntitiesObserver = Sketchup::EntitiesObserver::new
But I think you are beginning to understand that all the API observer classes are abstract. This means they do not have any functionality to pass down to their subclasses.
#remove_observer, as well as the SketchUp core (when it polls what it believes are observer objects,) … does not do any type checking.
It only does “duck-typing”, … to ask the object if it responds to named callback methods.
So this means that observers do not have to be implemented as a class. And if they are, they actually do not need to be a subclass of any observer superclass in particular.
Also, you can create hybrid observers that have the mixed functionality from multiple observer “classes”.
If you only need 1 observer, then it could also a single module. (I myself use a module quite often.)
Or as you showed above it could an instance of something else, to which you define a singleton callback “on the fly”.
In summation, SketchUp only cares that an observer object has a public callback method that it can call for a particular situation.